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 protected] To: [email protected] 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 protected]> 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 protected]> || Professor of Computer Science || http://www.cs.yale.edu/~yry/ | ===================================== _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
