Subject: Re: [alto] State of the WG

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Fri, 13 May 2016 17:47:10 +0000

Hi Kai,

Great thanks for your review. Please find my answers inline.  Your questions stress the need for clarifications in the next draft version and raises questions on which it would be good to have the opinions of the list.
Thanks,
Sabine

De : alto [mailto:[email-masked]] De la part de EXT Gao Kai
Envoyé : mardi 23 février 2016 08:51
À : Gurbani, Vijay (Nokia - US); IETF ALTO
Objet : Re: [alto] State of the WG

Hi all,

Below are my feedbacks on the multi-cost draft:

Review on draft-ietf-alto-multi-cost-01:

Notation:
sec#X: Section X
para#X: paragraph X
line#X: line X
=====

sec#1-para#1-line#3:
Typo: "such" -> "such as"

sec#1-para#7-line4:
Typo: "definition" -> "definitions"
[SR     ] Thanks for pointing them

sec#3.6:

Instead of reusing the "constraints" field for "testable-cost-types", I'd like
to propose that we enforce the use of "or-constraints".
[SR     ] you mean: whenever is "testable-cost-types" used which implies the ALTO Client (AOC) is Multi-Cost (MCA) capable, we may want to enforce the use of "or-constraints"? Given that  a legacy AOC then just uses member "constraints" as specified in RFC7285, I don't see an objection to this. The design intention was to support a MCA AOC that does not want care about OR constraints. With or-constraints, a list of (and-)constraints would then just be an array of 1 member.
Any thoughts on the list?

Firstly, the format of "testable-cost-types" is a list of cost types, but the
"constraints" field is originally designed for testing one cost type.  Even
using the extended format, the conditions can only be concatenated by the AND
operator.  Using "or-constraints", on the other hand, provides better
flexibility.

Secondly, according to the draft, if the "testable-cost-types" is missing, the
servers will test the "multi-cost-types" with the conditions specified by
"or-constraints".  Thus using "or-constraints" for both cases can simplify the
implementation because the "constraints" field can be totally ignored in this
case.

Finally, from the example in section 5.4, I feel the extended usage of
"constraints" seems to be only designed for the special case that the number of
elements in "testable-cost-types" is 1, which I think the benefits are not
worth the complexity it brings to both clients and servers.
[SR     ] can you explain this latter point in example Nb3 section 5.4? A MCA AOC can use "constraints" when multiple "testable-cost-types" are used. In this example, the request input member could include 2 testable cost types RC and HC and constraints expressing: RC in [0, 10] AND HC in [0, 2]
which expand to: RC gt (i.e. Greater Than)  0 AND RC lt (Lower Than) 10  AND HC gt 0 AND HC lt 2
The corresponding input members could be:
"cost-type" : {
"cost-mode": "numerical", "cost-metric": "routingcost"
},
"testable-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "hopcount"}
],
"or-constraints": [
["[0] le 10", "[1] le 2", "[0] gt 0", "[1] gt 0"]

sec4.1.1-para#1:

The type of "or-constraints" should be:

    [JSONArray or-constraints<0..*>;]
[SR     ] thanks for pointing this
sec4.1.1:

In the description for "testable-cost-types", the first paragraph says it is
described for the "constraints" parameter, which should be for the
"or-constraints" parameter or, if we decide to reuse the "constraints" field,
for both parameters.

sec4.1.2:

The description for "testable-cost-type-names" capability indicates it requires
the "cost-constraints" capability to be "true".  However, in that case,
according to RFC 7285, all cost types should be able to be included in
constraints, which means they are "testable".  I cannot think of a good reason
of doing that so my proposal is that we do the opposite:
[SR     ] indeed, thanks for pointing this: If an MCA capable Server indicates several "cost-type-names", say ["num-rc", "num-hc"] but does not allow tests on "num-hc",  it can only indicate if with "testable-cost-type-names" set to [ "num-rc"].
However, a legacy AOC ignores the capability member  "testable-cost-type-names" but sees "cost-constraints: true" and therefore may place requests on "num-hc" with constraints on this cost.

When the "cost-constraints" is set to "true", all types are testable and the
"testable-cost-type-names" SHOULD NOT appear and MUST be omitted if it does.
Otherwise, only the types specified in the "testable-cost-type-names" are
considered testable.
[SR     ] The latter solution may be an option. So we have:
Option 1:  allow a MCA capable Server to have a list of testable cost types co-existing with "cost-constraints" implicitly set to "false". If we consider this as acceptable, we can take this option.
Option 2:  a MCA capable server allows tests on all listed cost type names. In which case, there is no use for member "testable-cost-type-names".
In both cases, an AOC may use member "testable-cost-types" when it requires metric values for a list "multi-cost-types" with constraints on metrics not listed in "multi-cost-types".
Any thoughts on the list?

You thoughts and opinions are highly appreciated!

Regards,
Kai
On 23/02/16 09:48, Gao Kai wrote:
Hello Vijay and all,

I can go through the WG drafts 2 and 3 (the SSE and Multi-cost) and give some feedbacks as soon as possible.

Regards,
Kai
On 26/01/16 23:29, Vijay K. Gurbani wrote:
Folks: The mailing list has been awfully quiet.

Presently, we have 3 active I-Ds that are being tracked towards charter
fulfillment:

1. draft-ietf-alto-deployments is in its second WGLC.  The new WGLC ends
 on February 3, 2016.

2. draft-ietf-alto-incr-update-sse appears to be moving along and there
 do not seem to be any stop gap issues that we are aware of.  Authors,
 please inform the WG if there are.

3. draft-ietf-alto-multi-cost is also fairly mature.

It seems reasonable to move 2 and 3 ahead.

Then there are a number of independent submissions dating back to Sep-
Oct 2015 timeframe.  These have not been updated and nor has there been
much discussion on the mailing list.  Some of these submissions are
important for charter deliverables related to graph representation
formats.  Can the authors of the independent submissions kindly
share what their plans are with respect to the drafts?

This will help us gauge whether or not we should meet face-to-face in
Buenos Aires or have an interim meeting before it and meet face-to-face
in Berlin.

Note that while the final plans are still up in the air and subject
to change, there is a good chance that neither Jan or I will be able to
make it to Buenos Aires.  However, if a F2F meeting is desired, it is
important to get a sense of the energy behind the independent drafts,
as the list traffic has been woefully quiet on this front.

Thanks,

- vijay

_______________________________________________

alto mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/alto

---

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Fri, 13 May 2016 17:55:54 +0000

Hi Qiao,
Great thanks for your review. Please find my answers inline.  Your questions stress the need for clarifications in the next draft version.
Thanks,
Sabine

De : alto [mailto:[email-masked]] De la part de EXT Qiao Xiang
Envoyé : mardi 1 mars 2016 21:45
À : Gao Kai; IETF ALTO
Objet : Re: [alto] State of the WG

Hi All,

The following are my comments on draft-ietf-alto-multi-cost-01:

Some typos:
Sec 1, paragraph 5, "RTT" -> "Round Trip Time (RTT)"

Sec 2, paragraph 2, "refering" -> "referring"
Sec 2, move the abbreviation "Content Delivery Networks (CDN)" to the 2nd paragraph of Sec 1, where it appears in the draft for the first time.

Sec 4.1.1, the paragraph of "multi-cost-types", second line: "thlis" -> "the"
[SR     ] Thanks for pointing the typos. Will be corrected in upcoming version

Comments on testable-cost-types and multi-cost-types:

I am a bit confused about "testable-cost-types". From the example in Sec 5.2, "cost-type" and "testable-cost-types" can coexist.
[SR     ] Do you refer to example #3 in section 5.4 ?
And when they do, the constraint will be applied to "testable-cost-types". But from the description in paragraph 2 on page 10, it seems that if "multi-cost-types" exists, test will be applied only to "multi-cost-types", not "testable-cots-types".
[SR     ] If you refer in page 10/para 2 to the description of members "multi-cost-types" and “testable-cost-types” I don’t see what in the description implies this. There is an example on page 9 where both exist. But I understand a clearer formulation is needed. Would you please point in the text what makes you think this so that we can figure a better formulation?

What if a client wants to get routingcost and delaycost when routingcost, delaycost and hopcount all satisfy certain constraints? In this case, there are two costs in "multi-cost-type", but three types of costs are desired to be tested. It seems the current design does not allow client to express a request like this.
[SR     ] the design actually does allow it and your example illustrate how input member "testable-cost-types" can be useful (see also example #3 section 5.4 page 18). In your example the request will have members

"multi-cost-types" : [

"testable-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "hopcount"},
{"cost-mode": "numerical", "cost-metric": "delaycost"}
],
with a "constraints" or "or-constraints" member which  implies of course that the "cost-type-names" capability of the filtered Cost Map includes at least the names of the 3 listed “testable-cost-types”.

It would be great if anyone could shed some lights on this issue. Thank you very much.
[SR     ] I hope my answers helped let me know if not.

Best
Qiao
[SR     ] Thanks
Sabine

On Tue, Feb 23, 2016 at 2:51 AM, Gao Kai <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Notation:
sec#X: Section X
para#X: paragraph X
line#X: line X
=====

sec#1-para#1-line#3:

sec#1-para#7-line4:

sec#3.6:

sec4.1.1-para#1:

sec4.1.1:

sec4.1.2:

Regards,
Kai

Regards,
Kai

Thanks,

- vijay

alto mailing list

--
Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University