Subject: [alto] First set of comments on draft-ietf-alto-multi-cost-00.txt

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 20 Jul 2015 13:10:00 +0800

Dear Sabine, Wendy, Nico,

Great work in the multi-cost document! I read the first sections (before
Section 4, which provides the formal grammar). I will dig into the formal
spec in the next one or two days. In the mean time, please see below for
initial (some quite minor) comments.

=====
page 4:
  IETF has designed a new service called ALTO that provides guidance to
   overlay applications, which have to select one or several hosts from

 [yry] Is there a need to emphasize on overlay?

  This guidance is based on parameters that affect performance and
   efficiency of the data transmission between the hosts, e.g., the
   topological distance.  The purpose of ALTO is to improve Quality of

 [yry] The location of "e.g., ..." makes it a bit hard to read. I assume
that it is an example of guidance? If so, how about move to be after "This
guidance"?

  System (AS).  Together with this Network Map, it provides the

 [yry] "this Network Map" is not defined.

   Last, it provides the Ranking of Endpoints w.r.t. their routing cost.

 [yry] The preceding is cost map centric. Since there is also the ECS, how
about mention cost map just as an example?

   It would be ...
   emerging applications that need information on several Cost Types,
   having them gathered in one map will save time.

  [yry] Another potential aspect is consistency: since it is a single
batch,
  it is less likely to be inconsistent.

page 5:
  o  {1.2.3}: References of this form are to sections in the ALTO
      protocol specification [RFC7285].

[yry] What if you want to refer to a section in this document? Maybe
mention that if it is a section in this document, there will be no {}?

     client to include the case of a CDN client, a client of an
      application running on a virtual server, a GRID application client

[yry] GRID or Grid?

page 6:
   The multi-cost extensions defined in this document should not break
   legacy implementations (that is, clients and servers which are not
   aware of these extensions).

[yry] "should not" is not a normative term here. I wonder what a legacy
client will behave if it seems an array. One issue is that the "meta"
field will not be compatible.

page 7:
                               "num-hopcount" ],
          ...
        }

[yry] The max-cost-types is 3, and the example has two types. So it is an
example of max?

page 8:
   This document uses the technique described above to extend Endpoint

 [yry] replace "above" with Section 3.3?

   destination PIDs.  Hence a client can use an extended Filtered Cost
   Map resource to get a full Multi Cost Map.

[yry] So the implication is that multi cost maps are provided and
retrieved only by filtered cost maps? How about make it clear upfront, in
intro?

page 8:
  Second, the "AND" of simple predicates is not sufficient; to be
   useful, clients must be able to express "OR" tests.  Hence we add a

[yry] To support "is not sufficient", how about refer to the previous
example using or?

page 8:
  Thus the following request tells the server to limit its response to
   cost points with "routingcost" <= 100 AND "hopcount" <= 2, OR else
   "routingcost" <= 10 AND "hopcount" <= 6:

[yry] So it is disjunctive normal form without not? Then why not include
"not", to be compete?

page 9:
4.  Protocol Extensions for Multi-Cost ALTO Transactions

[yry] How about adding a transition sentence to say that now it is formal
spec?

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 20 Jul 2015 13:34:37 +0800

Sabine, Wendy, Nico,

My previous comments focused more on the details. At a high level, I feel
that the current writeup did reflect fully the principle and the cleverness
in your design :-)

For example, for both Introduction and Overview, I would use the following
storyline:
- Multi cost is beneficial (already exists)
- What are the design options then?
  Option 1: introduce a new media type? But one should follow a principle
of minimizing the number of media types, avoid duplication, ...
  Option 2: Assume no media type. First show that full cost map cannot be
extended.
  Then your key insight is that filtered cost map (whose capabilities field
allows multiple cost types already) allows the introduction of multicost
without the need of a new media-type, assuming conforming client behaviors.

I feel that the preceding will make the document easier to understand.

Do I understand you correctly?

I will read the detailed grammar next.

Richard

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

---

From: wangxin <[email-masked]>
Date: Mon, 20 Jul 2015 08:32:09 +0000

Dear Sabine, Wendy, Nico,
It's a great idea that adding multi-cost, or-constraints, and testable-cost-types (I like this very much). And here are my some comments about the design (mainly focus on Section 4 and 5).
=========================Page 9:
"If the "testable-cost-types" parameter is present, .... Otherwise, if the"multi-cost-types" parameter is present, .... If neither of those parameters are presents, ..."
First, "neither of ... are" should be "neither of ... is".
Second, for me, it's not easy to fully understand the relation between constraints, testable-cost-types, and multi-cost-types. Considering the SELECT statement (as you take as an example) in database, constraints are always at WHERE statement. And WHERE statement is quite similar to your testable-cost-types. So I suggest that constraints are always for testable-cost-types. If the "testable-cost-types" parameter is not defined, ALTO server considers it is equal to cost-type or multi-cost-types (there is only one parameter from both). Then it would be quite simple that constraints are only for testable-cost-types (like WHERE), and cost-type and multi-cost-types are for the return parameter (like SELECT).
=========================Page 11:
"max-cost-types: If present with value N..."
Is it possible that N is less than the number in multi-cost-types? If it is possible, what situation makes it happen?
=========================
Page 14:
Content-Length: [TODO]
Maybe should remove TODO
=========================
Thanks,Xin

Date: Mon, 20 Jul 2015 13:34:37 +0800
From: [email-masked]
To: [email-masked]
Subject: Re: [alto] First set of comments on	draft-ietf-alto-multi-cost-00.txt

Sabine, Wendy, Nico,
My previous comments focused more on the details. At a high level, I feel that the current writeup did reflect fully the principle and the cleverness in your design :-) 
For example, for both Introduction and Overview, I would use the following storyline:- Multi cost is beneficial (already exists)- What are the design options then?  Option 1: introduce a new media type? But one should follow a principle of minimizing the number of media types, avoid duplication, ...  Option 2: Assume no media type. First show that full cost map cannot be extended. 
  Then your key insight is that filtered cost map (whose capabilities field allows multiple cost types already) allows the introduction of multicost without the need of a new media-type, assuming conforming client behaviors.
I feel that the preceding will make the document easier to understand.
Do I understand you correctly?
I will read the detailed grammar next.
Richard
On Mon, Jul 20, 2015 at 1:10 PM, Y. Richard Yang <[email-masked]> wrote:
Dear Sabine, Wendy, Nico,

Great work in the multi-cost document! I read the first sections (before Section 4, which provides the formal grammar). I will dig into the formal spec in the next one or two days. In the mean time, please see below for initial (some quite minor) comments.
=====page 4:  IETF has designed a new service called ALTO that provides guidance to   overlay applications, which have to select one or several hosts from
 [yry] Is there a need to emphasize on overlay?
  This guidance is based on parameters that affect performance and   efficiency of the data transmission between the hosts, e.g., the   topological distance.  The purpose of ALTO is to improve Quality of
 [yry] The location of "e.g., ..." makes it a bit hard to read. I assume that it is an example of guidance? If so, how about move to be after "This guidance"?
  System (AS).  Together with this Network Map, it provides the
 [yry] "this Network Map" is not defined.
   Last, it provides the Ranking of Endpoints w.r.t. their routing cost.
 [yry] The preceding is cost map centric. Since there is also the ECS, how about mention cost map just as an example?
   It would be ...   emerging applications that need information on several Cost Types,   having them gathered in one map will save time.
  [yry] Another potential aspect is consistency: since it is a single batch,   it is less likely to be inconsistent.
page 5:  o  {1.2.3}: References of this form are to sections in the ALTO      protocol specification [RFC7285].
[yry] What if you want to refer to a section in this document? Maybe mention that if it is a section in this document, there will be no {}?
     client to include the case of a CDN client, a client of an      application running on a virtual server, a GRID application client
[yry] GRID or Grid?
page 6:   The multi-cost extensions defined in this document should not break   legacy implementations (that is, clients and servers which are not   aware of these extensions).
[yry] "should not" is not a normative term here. I wonder what a legacy client will behave if it seems an array. One issue is that the "meta" field will not be compatible.
page 7:                               "num-hopcount" ],          ...        }
[yry] The max-cost-types is 3, and the example has two types. So it is an example of max?
page 8:   This document uses the technique described above to extend Endpoint
 [yry] replace "above" with Section 3.3?
   destination PIDs.  Hence a client can use an extended Filtered Cost   Map resource to get a full Multi Cost Map.
[yry] So the implication is that multi cost maps are provided and retrieved only by filtered cost maps? How about make it clear upfront, in intro?
page 8:  Second, the "AND" of simple predicates is not sufficient; to be   useful, clients must be able to express "OR" tests.  Hence we add a
[yry] To support "is not sufficient", how about refer to the previous example using or?
page 8:  Thus the following request tells the server to limit its response to   cost points with "routingcost" <= 100 AND "hopcount" <= 2, OR else   "routingcost" <= 10 AND "hopcount" <= 6:
[yry] So it is disjunctive normal form without not? Then why not include "not", to be compete?
page 9:4.  Protocol Extensions for Multi-Cost ALTO Transactions
[yry] How about adding a transition sentence to say that now it is formal spec? 

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

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

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Tue, 21 Jul 2015 12:30:51 +0000

Hi Richard,

Great thanks for your feedback. They help a lot clarifying things and will take them into account in a next iteration of the draft.
Best regards,
Sabine

De : alto [mailto:[email-masked]] De la part de Y. Richard Yang
Envoyé : lundi 20 juillet 2015 07:10
À : IETF ALTO
Objet : [alto] First set of comments on draft-ietf-alto-multi-cost-00.txt

=====
page 4:

   It would be ...

  [yry] Another potential aspect is consistency: since it is a single batch,
  it is less likely to be inconsistent.

page 5:

[yry] GRID or Grid?

page 6:

page 7:
                               "num-hopcount" ],
          ...
        }

page 8:

[yry] So the implication is that multi cost maps are provided and
retrieved only by filtered cost maps? How about make it clear upfront, in intro?

page 8:

page 8:

page 9:

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Tue, 21 Jul 2015 12:34:09 +0000

Hi Wangxin,

Thanks a lot for your feedback. We will consider them in the next draft iteration. Especially, we need to emphasize and clarify the text in the current version that explains the usage of "testable-cost-types" and the restriction to filtered Cost Map.
Best regards
Sabine

De : alto [mailto:[email-masked]] De la part de wangxin
Envoyé : lundi 20 juillet 2015 10:32
À : IETF ALTO
Objet : Re: [alto] First set of comments on draft-ietf-alto-multi-cost-00.txt

Page 9:

Page 11:

Page 14:

Content-Length: [TODO]

Maybe should remove TODO

Thanks,
Xin
________________________________
Date: Mon, 20 Jul 2015 13:34:37 +0800
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [alto] First set of comments on draft-ietf-alto-multi-cost-00.txt
Sabine, Wendy, Nico,

For example, for both Introduction and Overview, I would use the following storyline:
- Multi cost is beneficial (already exists)
- What are the design options then?
  Option 1: introduce a new media type? But one should follow a principle of minimizing the number of media types, avoid duplication, ...
  Option 2: Assume no media type. First show that full cost map cannot be extended.
  Then your key insight is that filtered cost map (whose capabilities field allows multiple cost types already) allows the introduction of multicost without the need of a new media-type, assuming conforming client behaviors.

Richard

On Mon, Jul 20, 2015 at 1:10 PM, Y. Richard Yang <[email-masked]<mailto:[email-masked]>> wrote:
Dear Sabine, Wendy, Nico,

=====
page 4:

   It would be ...

page 5:

[yry] GRID or Grid?

page 6:

page 7:
                               "num-hopcount" ],
          ...
        }

page 8:

page 8:

page 8:

page 9:

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

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