Hi Sabine, Thanks a lot for the quick response. See below.
On Tuesday, July 19, 2016, Randriamasy, Sabine (Nokia - FR) < [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
