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

["Y. Richard Yang" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================