Subject: Re: [alto] Review of draft-ietf-alto-multi-cost-02 (part 1)

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Wed, 3 Aug 2016 17:25:38 +0000

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-masked] [mailto:[email-masked]] 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-masked]<mailto:[email-masked]>> 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-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');> [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>] 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