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
On Sun, Jul 17, 2016 at 1:12 PM, Randriamasy, Sabine (Nokia - FR) <
[email protected]> wrote:
> Dear Xin,
>
>
>
> Thank you for your feedback. Please see answers inline and let me know if
> they address your questions. We will further try to clarify wherever is
> needed.
>
>
>
> Thanks,
>
> Sabine
>
>
>
>
>
>
>
> *De :* wang xin [mailto:[email protected] <[email protected]>]
>
> *Envoyé :* jeudi 7 juillet 2016 08:00
> *À :* Randriamasy, Sabine (Nokia - FR); [email protected];
> [email protected]
> *Cc :* IETF ALTO
> *Objet :* My review on multi-cost
>
>
>
> Dear authors,
>
>
>
> First, this draft looks concrete and interesting to me. It should be a key
> extension to RFC7285. Followings are my comments:
>
>
>
> 1. The third paragraph in Introduction section.
>
> In this paragraph, it mentions “cost values that change more frequently
> than previously assumed”. This is the only sentence in the whole draft
> trying to discuss the changing frequency of cost values. I didn’t find any
> further discussion in the content of the draft. Is it necessary to mention
> that? Or the draft should give some explanations for this sentence?
>
> *[SR ] The idea is to introduce the need to minimize the number of
> ALTO transactions for metrics with frequently changing values. Would the
> following phrasing address your question?*
>
> *“…, in particular cost values that change more frequently than previously
> assumed and thus require more frequent ALTO requests. Moreover, to be sure
> to have up to date values, applications using several frequently changing
> metrics will tend to refresh their values simultaneously.“*
>
>
>
> 2. Application Client (AC) in Terminology section.
>
> “Client” and “client” should have different meanings in this draft. The
> former one indicates Alto Client and the latter one is for the general
> client of applications. I think “… any Client that …” should use “client”?
>
> *[SR ] I agree with your concern. To get rid of ambiguities I suggest
> that we systematically use “ALTO client” and “application client. Would
> that be OK?*
>
>
>
> 3. Section 3.6.3 and Section 3.6.5
>
> These two sections mainly discuss “testable-cost-type-name” as well as
> “cost-constraints” fields in RFC7285. To be compatible with RFC7285, the
> exclusive requirement seems a little complicate to me. As the draft already
> defines a new capability, “test-cost-types”, why doesn’t define a new
> constraints for that, something like “testable-constraints”? This is
> different from “cost-constraints” in RFC7285 that a client uses
> “testable-constraints” to filter costs and doesn’t care the actual values.
> Is there any difficulties or problems for that?
>
> *[SR ] “testable-cost-type-name” is a field used in the IRD
> capabilities for resource "filtered-cost-map-extended" that does not allow
> constraints on all of the metrics it provides, see example in section
> 3.6.5. *
>
> *The field “cost-constraints” is a Boolean capability of resource
> "filtered-multicost-map" compatible with RFC7285. That means this resource
> MUST allow constraints on all the metrics it provides. *
>
> *This distinction is done for legacy ALTO clients because they do not see
> the capability fields “testable-cost-type-name”, "max-cost-types" since
> they are not defined in RFC7285. The presence of these fields ensures that
> legacy clients can safely use both resources . For example, a legacy client
> using “filtered-cost-map-extended" will not use constraints on this
> resources as there is no capability “cost-constraints: true”. *
>
>
>
> 4. Section 4.1.1
>
> The definition of FilteredCostMapCapabilities doesn’t reflect the
> exclusive requirement for “cost-constraints” and
> “testable-cost-type-names”. Maybe it should add two types of
> FilteredCostMapCapabilities to reflect that or this is not important.
>
> *[SR ] this section is a formal specification of the descriptions in
> sections 3.6.3 and 3.6.5. The description of member
> “testable-cost-type-names ”, in its second paragraph states that: *
>
> *“"testable-cost-typenames" and "cost-constraints" are mutually exclusive
> to prevent legacy clients from issuing constraint tests on untestable cost
> types”*
>
> *Do you think we should better highlight this rule? *
>
>
>
> Thanks,
>
> Xin
>
> _______________________________________________
> alto mailing list
> [email protected]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=Yc0ic_g9A_mspPPyXGFPTHB2r6rcV7gnpOEAMbWcMkM&s=vWKTKujH_bCDwLgQ8VnVYEh9NreNQfi-ipz_2obeg0o&e=
>
>
--
--
=====================================
| 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
