Subject: [alto] TR: I-D Action: draft-ietf-alto-multi-cost-02.txt

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Tue, 14 Jun 2016 09:30:52 +0000

Hi Kai, Qiao, Fred and all,

We have posted a new version of Multi-Cost ALTO according to your feedback. For short:

- The extensions overview on "testable-cost-type-names", "constraints" and "or-constraints" has been further clarified with additional subsections see 3.6.1 to 3.6.5, 

- the design for the testable-cost-type-names capability (section 4.1.1) has been updated according to Kai's feedback:  "testable-cost-type-names" and "cost-constraints" are now mutually exclusive to prevent legacy clients from issuing constraint tests on untestable cost types, 

- the text on "constraints" and "or-constraints" input members in section 4.1.2 has been updated accordingly,
  
- the or-constraint member has been corrected to [JSONString or-constraints<0..*><0..*>;], 
  please note that this member will be corrected to [JSONString or-constraints<1..*><1..*>;] in the next draft version.

- the ipv4 examples in section 5.6 have been extended with ipv6 examples,

Again thank you all for your valuable comments. 

Please take a look and let us know if these updates meet your expectations,
Thanks,

Sabine, Wendy

>>-----Message d'origine-----
>>De : alto [mailto:[email-masked]] De la part de internet-
>>[email-masked]
>>Envoyé : lundi 13 juin 2016 18:15
>>À : [email-masked]
>>Cc : [email-masked]
>>Objet : [alto] I-D Action: draft-ietf-alto-multi-cost-02.txt
>>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>>This draft is a work item of the Application-Layer Traffic Optimization
>>of the IETF.
>>
>>        Title           : Multi-Cost ALTO
>>        Authors         : Sabine Randriamasy
>>                          Wendy Roome
>>                          Nico Schwan
>>	Filename        : draft-ietf-alto-multi-cost-02.txt
>>	Pages           : 27
>>	Date            : 2016-06-13
>>
>>Abstract:
>>   The ALTO (Application Layer-Traffic Optimization) Protocol
>>   ([RFC7285]) defines several services that return various metrics
>>   describing the costs between network endpoints.  For example, when
>>   downloading a file that is mirrored on several sites, a user
>>   application may use these ALTO cost metrics to determine the most
>>   efficient mirror site.
>>
>>   An ALTO Server may offer a variety of cost metrics, based on
>>latency,
>>   bandwidth, hop count, jitter, or whatever else the ALTO Server deems
>>   useful.  When selecting a mirror site, a client may consider more
>>   than one metric, perhaps trading bandwidth for latency.  While the
>>   base ALTO Protocol allows a client to use more than one cost metric,
>>   to do so, the client must request each metric separately.  This
>>   document defines a new service that allows a client to retrieve
>>   several cost metrics with one request, which is considerably more
>>   efficient.  In addition, this document extends the ALTO constraint
>>   tests to allow a user to specify an arbitrary logical combination of
>>   tests on several cost metrics.
>>
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-ietf-alto-multi-cost/
>>
>>There's also a htmlized version available at:
>>https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02
>>
>>A diff from the previous version is available at:
>>https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-multi-cost-02
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission until the htmlized version and diff are available at
>>tools.ietf.org.
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>ftp://ftp.ietf.org/internet-drafts/
>>
>>_______________________________________________
>>alto mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/alto

---

From: Hans Seidel <[email-masked]>
Date: Mon, 20 Jun 2016 16:34:32 +0200

Sabine, Wendy,

Below, my comments/questions on draft-ietf-alto-multi-cost-02.txt.

S4.1.2 "constraints" paragraph:

If I get this correct, in case "max-cost-types" > 0 and extended 
predicates are used, the logical OR applies instead of logical AND.
Why changing the behavior? Is there an advantage in using the logical OR?

What is used if no extended predicates are used, for example when a 
legacy client is requesting a multi-cost resource?
I assume the logical AND as stated in RFC7285 but it is not entirely 
clear to me.

How can a server distinguish between RFC7285 predicates and the new 
extended predicates?
Here, I am especially thinking of the case, that cost type index "0" can 
be omitted and the extended predicate becomes indistinguishable from 
RFC7285 predicates.

In general, I noticed some upper/lower case inconsistencies for certain 
nouns on several occasions. E.g. "client" and "Client" or "endpoint" and 
"Endpoint".
For consistency reasons only one notation should be used.

Regards
Hans

---

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Wed, 22 Jun 2016 14:24:47 +0000

Hi Hans,

Thanks a lot for your feedback. Please find answers to your questions inline. Don't hesitate to get back with further questions as it may help for the next draft version. 

Thanks,
Sabine

>>De : alto [mailto:[email-masked]] De la part de Hans Seidel
>>Envoyé : lundi 20 juin 2016 16:35
>>À : Randriamasy, Sabine (Nokia - FR); Kai GAO; Qiao Fu; [email-masked]
>>Cc : [email-masked]
>>Objet : Re: [alto] TR: I-D Action: draft-ietf-alto-multi-cost-02.txt
>>
>>Sabine, Wendy,
>>
[SR     ] 
[SR     ] It is perfectly fine for a MC(Multi-Cost) capable client to specify a "constraint" parameter composed by an array of extended predicates related by an AND.
The "constraints" description just stresses that the client cannot specify both "constraints" and "or-constraints". The "or-constraints" specification supports "constraints". For example:

a client willing to express "b in [12, 20] and r in [1, 10]" using "constraints" formulates it as follows, (assuming [0], [1] are the indexes of metrics b and r:

  ["[0] gt 12", "[0] le 20", "[1] gt 10", "[1] le 10"] 

A client willing to express "b in [12, 20] and r in [1, 10]" using "or-constraints" adds 2 brackets and formulates it as follows:
[
  ["[0] gt 12", "[0] le 20", "[1] gt 10", "[1] le 10"] 
]  

A client willing to express "(b > 12 and b < 20) or r < 10 or h < 2"  formulates the or-constraint as follows:
[
  ["[0] gt 12","[0] le 20"],
  ["[1] le 10],
  ["[2] le 20"]
]  

>>Why changing the behavior? Is there an advantage in using the logical
[SR     ] some MC clients may find it simpler to only use one type of extended constraints and thus "or-constraints" supporting both "and- only" and "and-or" combinations is an advantage. 

>>legacy client is requesting a multi-cost resource?
[SR     ] a legacy client is not allowed to request a multi-cost resource and must comply to RFC7285.

>>I assume the logical AND as stated in RFC7285 but it is not entirely
[SR     ] right, a legacy client MUST use the "constraints" member as specified in RFC7285

>>How can a server distinguish between RFC7285 predicates and the new
[SR     ] a legacy server will only understand legacy client requests. A MC Server MUST be able to understand both MC and legacy clients. 

>>Here, I am especially thinking of the case, that cost type index "0"
>>can be omitted and the extended predicate becomes indistinguishable
>>from
>>RFC7285 predicates.
[SR     ] a MC client must be able to talk with both MC Servers and legacy Servers. It MUST omit index "0" when interacting with a legacy server. It MAY omit it when requesting a single cost resource with constraints on that cost to a MC server. 
>>nouns on several occasions. E.g. "client" and "Client" or "endpoint"
>>and "Endpoint".
[SR     ] thanks a lot for notifying this. Will be corrected.

>>Hans
[SR     ] Thanks, Sabine
>>> - The extensions overview on "testable-cost-type-names",
>>"constraints"
>>> and "or-constraints" has been further clarified with additional
>>> subsections see 3.6.1 to 3.6.5,
>>>
>>> - the design for the testable-cost-type-names capability (section
>>> 4.1.1) has been updated according to Kai's feedback:
>>> "testable-cost-type-names" and "cost-constraints" are now mutually
>>> exclusive to prevent legacy clients from issuing constraint tests on
>>> untestable cost types,
>>>
>>> - the text on "constraints" and "or-constraints" input members in
>>> section 4.1.2 has been updated accordingly,
>>>
>>>    please note that this member will be corrected to [JSONString or-
>>constraints<1..*><1..*>;] in the next draft version.
>>>
>>> Please take a look and let us know if these updates meet your
>>> expectations, Thanks,
>>>
>>> Sabine, Wendy
>>>