Subject: [alto] I-D Action: draft-ietf-alto-multi-cost-02.txt

From: [email-masked]
Date: Mon, 13 Jun 2016 09:14:59 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization of the IETF.

        Title           : Multi-Cost ALTO
        Authors         : Sabine Randriamasy
                          Wendy Roome
                          Nico Schwan
	Filename        : draft-ietf-alto-multi-cost-02.txt
	Pages           : 27
	Date            : 2016-06-13

Abstract:
   The ALTO (Application Layer-Traffic Optimization) Protocol
   ([RFC7285]) defines several services that return various metrics
   describing the costs between network endpoints.  For example, when
   downloading a file that is mirrored on several sites, a user
   application may use these ALTO cost metrics to determine the most
   efficient mirror site.

   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.  When selecting a mirror site, a client may consider more
   than one metric, perhaps trading bandwidth for latency.  While the
   base ALTO Protocol allows a client to use more than one cost metric,
   to do so, the client must request each metric separately.  This
   document defines a new service that allows a client to retrieve
   several cost metrics with one request, which is considerably more
   efficient.  In addition, this document extends the ALTO constraint
   tests to allow a user to specify an arbitrary logical combination of
   tests on several cost metrics.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-multi-cost/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-multi-cost-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Wendy Roome <[email-masked]>
Date: Tue, 21 Jun 2016 10:11:21 -0400

Hans,

Thanks for reading it. Comments inline.

>Date: Mon, 20 Jun 2016 16:34:32 +0200
>From: Hans Seidel <[email-masked]>
>
>Sabine, Wendy,
>
>Below, my comments/questions on draft-ietf-alto-multi-cost-02.txt.
>
>S4.1.2 "constraints" paragraph:
>
>If I get this correct, in case "max-cost-types" > 0 and extended
>predicates are used, the logical OR applies instead of logical AND.
>Why changing the behavior? Is there an advantage in using the logical OR?

The intent is that if the server is multi-cost-aware (i.e., max-cost-types
> 0), then a client can use *either* an or-constraints parameter or a
>constraints parameter. So we extended the behavior, rather than changing
>it.

If a simple AND test is sufficient for the client, the client can use
"constraints". There is no advantage to using or-constraints unless the
client needs the OR of ANDs.

The two parameters are mutually exclusive, and I assume a multi-cost-aware
server will interpret a  constraints  parameter as just a short-cut for
or-constraints.

>What is used if no extended predicates are used, for example when a
>legacy client is requesting a multi-cost resource?
>I assume the logical AND as stated in RFC7285 but it is not entirely
>clear to me.

The intent is to be strictly upward compatible: multi-cost-aware servers
will accept RFC 7285 predicates.

We will look it over to see if we can make that clearer. And we would
welcome any suggestions as to how to clarify that.

>How can a server distinguish between RFC7285 predicates and the new
>extended predicates?
>Here, I am especially thinking of the case, that cost type index "0" can
>be omitted and the extended predicate becomes indistinguishable from
>RFC7285 predicates.

We designed the extended predicates to an extension of the RFC7285
predicates. Because the index is optional, and defaults to 0, a
multi-cost-aware server will interpret an RFC7285 constraint like  le 10
as  [0] le 10.

So strictly speaking, a multi-cost-aware server does not need to
distinguish between an extended predicate and an RFC 7285 predicate.

>In general, I noticed some upper/lower case inconsistencies for certain
>nouns on several occasions. E.g. "client" and "Client" or "endpoint" and
>"Endpoint".
>For consistency reasons only one notation should be used.

*Sigh* Yes, I know. We will look it over and clean it up.
Although I think RFC7285 had similar inconsistencies.

>Regards
>Hans

Thanks for the comments.

	- Wendy