Tony,
On Mon, Jul 18, 2016 at 4:09 AM, wang xin <[email protected]> wrote:
> Dear Richard and all,
>
> For the problem on Section 3.1, my thinking is that though it is
> incompatible with the definition in Section 11.2.3.6 in RFC7285, which
> specifies that the "meta" field of a cost map response MUST include the
> "cost-type" field, this would not cause an error for ALTO clients.
>
What I meant is that the response does not conform to the alto-costmap+json
media type syntax, and hence a standard (component) parser of this media
type should report an error.
> Considering that if an ALTO client receives the response like the example
> in Sec 3.1, the ALTO client is sure to be aware of the multi-cost
> extensions (actually, the multi-cost result is expected by the client),
> which is guaranteed by the input parameters in the cost map request. But I
> agree that the problem should be considered and solved.
>
> Some potential solutions: 1. Introducing new cost-type (by Richard's
> comment); 2. Including an empty cost-type field (just to be consistent with
> RFC7285).
>
>
> Hmm. For solution 2, an empty cost-type does not look elegant to me. One
possibility is to use the cost-type to "point to" the multi-cost-types
definition, forming some kind of "chaining" definition, e.g.,
"cost-type": {
"cost-mode": "multi-cost-types", "cost-metric": ?
}
"multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "hopcount"}
]
The key issue is whether we can use this as a general technique (aka
grammar) for the other use cases, such as path vector, cost calendar,
performance-stat objects, ...
Richard
Thanks,
>
> Xin
> ------------------------------
> *From:* alto <[email protected]> on behalf of Y. Richard Yang <
> [email protected]>
> *Sent:* Monday, July 18, 2016 6:22:35 AM
> *To:* IETF ALTO
> *Cc:* Wendy Roome; Nico Schwan
> *Subject:* [alto] 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."
>
> - 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."
>
> - 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.
>
> - 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."
>
> - 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?
>
> - 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?
>
> - 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
>
--
--
=====================================
| 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
