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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
