Subject: Re: [alto] ALTO extension for representing SDN policies

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 9 Apr 2015 14:15:49 -0400

Dear Huaming, Guohai,

Thanks for sharing the on the ALTO list.

I infer that the bigger picture you are thinking is to use ALTO maps to
convey end-to-end policies such as group based policies (GBP). The idea of
an endpoint group (EPG) in GBP is the same as the PID in ALTO. In fact,
initially PID was named as EPG.

Regardless of which one of the two approaches mentioned in your email, one
gap (of encoding GBP using an ALTO map) I see is that eventually the ALTO
WG has decided that there must be a mechanism to map each endpoint into a
single PID, and the longest prefix matching mechanism is the chosen
mechanism. I assume that you require the same?

Between the two approaches,  the first one maps more naturally into the
current ALTO usage model. But my understanding is that you will then have
multiple correlated cost maps, and there needs to be an ordering in
searching the maps. For example, one map has port=*, while the next has
port=80. I assume that you need to define some kind of priority/maximum
matching to define precisely the semantics. I do not understand why you
need QoS as a multiplex selector.

Thanks!
Richard

On Thu, Apr 9, 2015 at 10:49 AM, 郭华明 <[email-masked]> wrote:

> Hi Guohai,
>
> I think your example is good, it's my opinion that more meaningful
> policies are helpful for traffic optimization.
>
> -----原始邮件-----
> *发件人:*ChenGuohai <[email-masked]>
> *发送时间:*2015-04-08 21:18:44 (星期三)
> *收件人:* "郭华明" <[email-masked]>, "Richard Yang Y." <[email-masked]>
> *抄送:* "[email-masked]" <[email-masked]>
> *主题:* RE: [alto] Alto extension for representing SDN policies
>
>
>   Hi Huaming,All
>
> Getting policy rules does benefit to traffic optimization. In addition to
> that it can reduce ALTO request and response.
>
> For example, a policy is that band between a pair of src(A)and dst is 20M
> between 11:00 to 14:00 and is 10M for other time. And band between other
> src(B,C,D ....) and this dst is 15M. The ALTO client can use this policy
> in selecting more optimal peers without sending ATLO cost map request to
> ALTO server now and then.
>
> ALTO client select src(A) as the peer between 11:00 to 14:00 and one of
> src(B,C,D....) at other time.
>
> Make sense?
>
>
> BR
> Guohai
> ------------------------------
> Date: Tue, 31 Mar 2015 04:23:49 +0800
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> Subject: [alto] Ato extension for representing SDN policies
>
> Hi Richard, All
>
> In SDN, each pair of source and destination network could have multiple
> policy rules. These rules maybe include source/destination address,
> protocols, ports, QoS, actions and so on. This information is
> also important attributes of the path.
>
> I am thinking that if some policy information could be provided for
> applications in Alto, this is also helpful for traffic optimization.
>
> I think there are two methods to do that in Alto.
>
> 1, Use a multiple cost types in Cost Maps (similar ideas in
> draft-randriamasy-alto-multi-cost-10), add a new Cost Mode: policy, the
> Cost Metric use multiple fields, like <Protocol, Port, QoS>,  to represent a
> policy.
>
> 2, Add a new map service, like Policy Maps Service. In Policy Maps,
> applications can get the policy rule information.
>
>
> Thanks.
>
> --
> ----------------
> Best!
>
>
> Huaming Guo
>
> China Academy of Information and Communications Technology (CAICT)
>
> _______________________________________________ alto mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/alto
>
>
> --
> ----------------
> Best!
>
>
> Huaming Guo
>
> China Academy of Information and Communications Technology (CAICT)
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: 郭华明 <[email-masked]>
Date: Tue, 14 Apr 2015 04:50:02 +0800 (GMT+08:00)

Dear Richard,

The longest prefix matching mechanism in ALTO maps each IP address into a single PID, this is the non-overlapping property of an ALTO network map.  But in the end-to-end 
policies such as GBP, EPGs may be overlapped, some endpoints may belong to multiple EPGs, the longest prefix matching mechanism should be changed to adapt for that. 
I think that one prefix or IP address can be mapped into a PID list that contains one or multiple PIDs. We can still use the longest prefix matching, but the result is a PID list,
not a single PID.

I also like the first approach. There is only one cost map, but the cost metric has a policy list, each policy has  multiple fields, like Protocol, Port, QoS parameters, or other fields.

  "multi-cost-types" : [
        {"cost-mode": "policy", "cost-metric": "policy"},
        {"cost-mode": "policy", "cost-metric": "policy"}
      ]
    }
    "cost-map" : {
      "PID1": { "PID1":[null,null],   "PID2":[<TCP,80,10M>,<UDP,120,20M>]},
      "PID2": { "PID1":[<TCP,80,10M>,<UDP,120,20M>], "PID2":[null,null]}
         }

-----原始邮件-----
发件人:"Y. Richard Yang" <[email-masked]>
发送时间:2015-04-10 02:15:49 (星期五)
收件人: "郭华明" <[email-masked]>
抄送: ChenGuohai <[email-masked]>, "[email-masked]" <[email-masked]>
主题: Re: RE: [alto] ALTO extension for representing SDN policies

Dear Huaming, Guohai,

I infer that the bigger picture you are thinking is to use ALTO maps to convey end-to-end policies such as group based policies (GBP). The idea of an endpoint group (EPG) in GBP is the same as the PID in ALTO. In fact, initially PID was named as EPG.

Regardless of which one of the two approaches mentioned in your email, one gap (of encoding GBP using an ALTO map) I see is that eventually the ALTO WG has decided that there must be a mechanism to map each endpoint into a single PID, and the longest prefix matching mechanism is the chosen mechanism. I assume that you require the same?

Between the two approaches,  the first one maps more naturally into the current ALTO usage model. But my understanding is that you will then have multiple correlated cost maps, and there needs to be an ordering in searching the maps. For example, one map has port=*, while the next has port=80. I assume that you need to define some kind of priority/maximum matching to define precisely the semantics. I do not understand why you need QoS as a multiplex selector. 

Thanks!
Richard

I think your example is good, it's my opinion that more meaningful policies are helpful for traffic optimization.

-----原始邮件-----
发件人:ChenGuohai <[email-masked]>
发送时间:2015-04-08 21:18:44 (星期三)
收件人: "郭华明" <[email-masked]>, "Richard Yang Y." <[email-masked]>
抄送: "[email-masked]" <[email-masked]>
主题: RE: [alto] Alto extension for representing SDN policies

Hi Huaming,All

Getting policy rules does benefit to traffic optimization. In addition to that it can reduce ALTO request and response. 

For example, a policy is that band between a pair of src(A)and dst is 20M between 11:00 to 14:00 and is 10M for other time. And band between other src(B,C,D ....) and this dst is 15M. The ALTO client can use this policy in selecting more optimal peers without sending ATLO cost map request to ALTO server now and then. 

ALTO client select src(A) as the peer between 11:00 to 14:00 and one of src(B,C,D....) at other time.

Make sense?

BR
Guohai

Hi Richard, All

In SDN, each pair of source and destination network could have multiple policy rules. These rules maybe include source/destination address, protocols, ports, QoS, actions and so on. This information is
also important attributes of the path.     

I am thinking that if some policy information could be provided for applications in Alto, this is also helpful for traffic optimization.

1, Use a multiple cost types in Cost Maps (similar ideas in  
), add a new Cost Mode: policy, the Cost Metric use multiple fields, like <Protocol, Port, QoS>,  to represent a policy.

2, Add a new map service, like Policy Maps Service. In Policy Maps, applications can get the policy rule information.

Thanks.   

--

----------------
Best!

Huaming Guo

_______________________________________________ alto mailing list [email-masked]://www.ietf.org/mailman/listinfo/alto

--

----------------
Best!

Huaming Guo

--

--

----------------
Best!

Huaming Guo