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

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 17 Jul 2016 18:22:35 -0400

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

---

From: wang xin <[email-masked]>
Date: Mon, 18 Jul 2016 08:09:32 +0000

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. 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).

Thanks,

Xin

________________________________
From: alto <[email-masked]> on behalf of Y. Richard Yang <[email-masked]>
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,

- Sec. 1. Introduction:

- Sec. 1. Introduction

- Sec. 1. Introduction:

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,

- 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?

 {
    "meta" : {

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.

Thanks!
Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 18 Jul 2016 14:11:37 -0400

Tony,

On Mon, Jul 18, 2016 at 4:09 AM, wang xin <[email-masked]> 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-masked]> on behalf of Y. Richard Yang <
> [email-masked]>
> *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)
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Tue, 19 Jul 2016 15:53:36 +0000

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]<mailto:[email-masked]> [mailto:[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)

=====
Hi Sabine, Wendy, Nico,

[SR     ]  OK, we can replace with your text, and then continue with “while the base ALTO protocol ([RFC7285]) allows a client…”

- Sec. 1. Introduction:

[SR     ] OK, fine with me

- Sec. 1. Introduction

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.

- Sec. 1. Introduction:

"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 ..."

 {

    "meta" : {

      "multi-cost-types" : [

      ]

    }

    "cost-map" : {

      ...

    }

   }

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.

- Sec. 3.2

Thanks!
Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 19 Jul 2016 16:18:41 -0400

Hi Sabine,

Thanks a lot for the quick response. See below.

On Tuesday, July 19, 2016, Randriamasy, Sabine (Nokia - FR) <
[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)
>
>
>
> *[SR     ]  OK, we can replace with your text, and then continue with
> “while the base ALTO protocol ([RFC7285]) allows a client…”*
>
>
>
> - Sec. 1. Introduction:
>
> *[SR     ] OK, fine with me*
> *[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 ...

> *[SR     ] agree. We will add this clarification.*
>
>
>
> - Sec. 2. Terminology
>
>
> *[SR     ] agree. We will rephrase. Would the following be OK? *
> "Endpoint (EP): *an endpoint can be for instance a*  Peer, a ..."
>
>
>
Okay.

> *[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

-- 
Richard