Hi all, In our last ALTO WG meeting in Berlin, there was a discussion on Multi-Cost ALTO responses specified in section 3.1 of draft https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02
In summary: RFC 7285 specifies a media-type “application/alto-costmap+json” for Cost Map responses. Its meta specification in section 11.2.3.6 says that “The "meta" MUST also include the "cost-type" field”. Richard points that a Multi-Cost ALTO response conveys Filtered Cost Maps defined in the Multi-Cost draft as having the media-type “application/alto-costmap+json”. However in this case there is no meta "cost-type" but "multi-cost-type" instead. In which case, those Multi-Cost responses cannot be defined as having media type “application/alto-costmap+json” . Even if neither legacy not multi-cost ALTO Client will have any problem parsing responses, there is a problem saying a Multi-Cost response conveys a given media-type where as the mandatory fields of this media-type are not all present. One way around was discussed during the meeting: put both a dummy "cost-type" field and a "multi-cost-type" with the actual cost-type list. Is there any objection in the WG to so? Please feel free to suggest any other way to solve this issue. Thanks, Sabine De : [email protected] [mailto:[email protected]] De la part de Y. Richard Yang Envoyé : mardi 19 juillet 2016 22:19 À : Randriamasy, Sabine (Nokia - FR) Cc : IETF ALTO; Roome, Wendy (Nokia - US); Nico Schwan Objet : Re: Review of draft-ietf-alto-multi-cost-02 (part 1) Hi Sabine, Thanks a lot for the quick response. See below. On Tuesday, July 19, 2016, Randriamasy, Sabine (Nokia - FR) <[email protected]<mailto:[email protected]>> wrote: Hi Richard, Thanks for your feedback and suggestions, please see answers inline. I answered until Sec 3.1 included as I think your comment on section 3.2 should be discussed in a separate thread. Thanks, Sabine De : [email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');> [mailto:[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>] De la part de Y. Richard Yang Envoyé : lundi 18 juillet 2016 00:23 À : IETF ALTO Cc : Randriamasy, Sabine (Nokia - FR); Roome, Wendy (Nokia - US); Nico Schwan Objet : Review of draft-ietf-alto-multi-cost-02 (part 1) This is a re-sent of a previous reply, to have a clean thread and also to fix an email address typo in the previous thread. ===== Hi Sabine, Wendy, Nico, Here are some more comments on multi-cost-02: - Abstract: "When selecting a mirror site, a client may consider more than one metric, perhaps trading bandwidth for latency." This can read as a general statement, but my understanding is that it is a continuation of the example. How about restructuring the abstract a bit, say: " The ALTO (Application Layer-Traffic Optimization) Protocol ([RFC7285]) defines several services that return various metrics describing the costs between network endpoints, and an ALTO Server may offer a variety of cost metrics, based on latency, bandwidth, hop count, jitter, or whatever else the ALTO Server deems useful. For example, when downloading a file that is mirrored on several sites, a user application may use more than one metric, perhaps trading bandwidth for latency, to determine the most efficient mirror site." [SR ] OK, we can replace with your text, and then continue with “while the base ALTO protocol ([RFC7285]) allows a client…” - Sec. 1. Introduction: "IETF has designed a new service called ALTO that provides guidance to overlay applications, which have to select one or several hosts from a set of candidates that are able to provide a desired resource." How about some small revisions: "IETF has defined ALTO services [RFC7285] to provide guidance to applications that need to select one or several hosts from a set of candidates that are able to provide a desired resource." [SR ] OK, fine with me - Sec. 1. Introduction "Current ALTO Costs and their modes provide values that are seen to be stable over a longer period of time, such as hopcount and administrative routing cost to reflect ISP routing preferences. Recently, new use cases have extended the usage scope of ALTO to Content Delivery Networks (CDN), Data Centers and applications that need additional information to select their Endpoints or handle their PIDs." Thus a multitude of new Cost Types that better reflect the requirements of these applications are expected to be specified, in particular cost values that change more frequently than previously assumed." Do you need to make the statement on "to be stable ..."? I feel that the consistency statement in a following paragraph is good enough. [SR ] the idea is to point “stability” as a characteristic of metrics foreseen during the design of the legacy ALTO protocol and point the evolution of new candidate metrics towards more dynamicity. I agree that alto may start to handle more dynamic info. My understanding is that you are using dynamics to motivate the need of the design---essentially a single transaction to get consistent data. The first paragraph ends with the requirement (more information). How about add a sentence for the next: "... to be specified. Handling multiple costs, however, can add more complexities, such as overheads and consistency, in particular ... when ... - Sec. 1. Introduction: "The ALTO protocol [RFC7285] restricts ALTO Cost Maps and Endpoint Cost services to only one Cost Type and Cost Mode per ALTO request." In later paragraphs, the document uses the phrase base protocol, and this can be a good place to say that when you say base it is this RFC, for example, "The ALTO protocol [RFC7285], which this document refers to as the base protocol, restricts ALTO Cost Maps and Endpoint Cost services to only one Cost Type and Cost Mode per ALTO request." [SR ] agree. We will add this clarification. - Sec. 2. Terminology "Endpoint (EP): A Peer, a ..." What if the list is not exhaustive. How about make it clear that they are just examples? [SR ] agree. We will rephrase. Would the following be OK? "Endpoint (EP): an endpoint can be for instance a Peer, a ..." Okay. - Sec. 3. Overview of Approach This is the place where I want to have a good discussion. - Sec. 3.1: First, the example in 3.1 of the draft: { "meta" : { "dependent-vtags" : [ ... ], "multi-cost-types" : [ {"cost-mode": "numerical", "cost-metric": "routingcost"}, {"cost-mode": "numerical", "cost-metric": "hopcount"} ] } "cost-map" : { "PID1": { "PID1":[1,0], "PID2":[5,23], "PID3":[10,5] }, ... } } According to {11.2.3.6}, there is this paragraph: "The "meta" field of a cost map response MUST include the "dependent-vtags" field, whose value is a single-element array to indicate the version tag of the network map used, where the network map is specified in "uses" of the IRD. The "meta" MUST also include the "cost-type" field, whose value indicates the cost type (Section 10.7) of the cost map." The second "MUST" in RFC 7285 can cause issues, right? The reason is that this MUST requires a cost-type field, but the newer encoding will not have a "cost-type" field but a "multi-cost-types" field in the response. Do I miss anything? My feeling is that we need to introduce new cost-type to handle the issue. Make sense? [SR ] As I will recall during the session, the Multi-Cost design is based on the following Legacy ALTO (i.e. RFC7285) compatible design principle: “A legacy ALTO Client must be able to send legacy requests to a Multi-Cost aware ALTO Server and get legacy responses as specified in RFC7285” As a consequence: - A legacy ALTO client will allways send legacy requests to a MC-ALTO Server and see "cost-types" in responses meta - Only MC ALTO Client will see "multi-cost-types" Does this address your concerns? The expressed principle is explicit and maybe there should be a placeholder to write it explicitly in the draft. My main concern is that including multi-cost-types without cost-type violates a MUST requirement on the alto-costmap media type... Richard - Sec. 3.2 I liked this discussion on compatibility with legacy clients. Using my understanding of RESTful thinking, there is a sequence of resources (aka a state machine) a client will visit, e.g., IRD -> cost map 1 in this case. This discussion/design is that by using the requirement of ignoring unknown field, a legacy client will not wonder into a new type of resource which it does not understand. Hence, the client will not "crash". This is very clever. Such ignoring unknown fields requirements, however, could lead to errors if a client has entered into the state machine. Let me stop here so that we can discuss on the question on Sec. 3.1. Thanks! Richard -- Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
