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

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: yry@cs.yale.edu
To: alto@ietf.org
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 <yry@cs.yale.edu> 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 <yry@cs.yale.edu>   || Professor of Computer Science       || http://www.cs.yale.edu/~yry/        | =====================================

_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto 		 	   		  