Re: [alto] WGLC: draft-ietf-alto-protocol-11

[Richard Alimi <[e-mail]>]

adding alto WG back...

On Sat, May 12, 2012 at 11:59 PM, Richard Alimi <[e-mail]> wrote:
> On Fri, May 11, 2012 at 11:15 AM, Sabine Randriamasy
> <[e-mail]> wrote:
>>
>>
>> Hi all,
>>
>> Below is my review of document "draft-ietf-alto-protocol-11.txt". At least
>> Part I, until section 7.7.3.1.5 included. I will send Part II in a couple of
>> hours.
>>
>> Thanks,
>> Sabine
>>
>> ===============================================================================================
>>
>>
>> Document: draft-ietf-alto-protocol-11.txt
>> Title: ALTO Protocol
>> Reviewer: Sabine Randriamasy
>> Review Date: May 11, 2012
>> Part I
>>
>> -----------------------------------------------------
>> GENERAL COMMENTS
>> -----------------------------------------------------
>>
>> This document seems geared towards P2P applications, although the abstract
>> mentions CDN and "those that have a choice in connection endpoints". In some
>> places, see detailed comments, "peer" should be replaced by "endpoints" when
>> referring to a content location. In Section 8 Use Cases, some text should be
>> added to recall this.
>
> Yes - that sounds reasonable.  We'll do a search for the word 'peer'
> to see if a better term can be used, and also add a reminder in the
> use cases that P2P is not the only deployment setting.
>
>> There was a discussion on whether to specify the MUST of the protocol. Is it
>> possible to have a section listing the MUST of the protocol specified in
>> this document?
>
> I don't recall this discussion - do you have a pointer?
>
> If I'm understanding the proposal correctly, I am concerned about how
> much duplicate information that would generate.  Is there an example
> RFC you could reference that does this?
>
>>
>> -----------------------------------------------------
>> DETAILED COMMENTS
>> -----------------------------------------------------
>>
>> Section 1.1 Background and Problem Statement
>>
>> A couple of additional explanations would help better positioning and
>> motivating ALTO. For example:
>>
>> - § 1 after 1st sentence "Today, network information available to
>> applications is mostly from
>> the view of endhosts.": I suggest to add 1 or 2 sentences on what is wrong
>> with this, e.g. the fact that overlay based endpoint choice leads to
>> uselessly use expensive links and lower performance due to too long paths.
>
> We can add something there. A better way to phrase this might be that
> a view only from the view of the endhosts makes it
> difficult/impossible to be aware of policies or properties of the
> overall network topology.
>
>> - §1, 2nd sentence "There is no clear mechanism to convey information about
>> the network (e.g., preferences) to applications": could be specified by
>> saying that some sparse tools may exist but there is a need to have a
>> generic and standardized mechanism accessible to all.
>
> Just to be sure I understand, which specific tools were you thinking
> about here?  BGP looking glasses or whois?  Or others?
>
>> - §2last sentence "The mechanism should include abstractions to achieve
>> concise, flexible network information expression.": is it the only
>> motivation for abstraction or does abstraction also serve other purposes
>> such as security/privacy for ISPs?
>
> I would tend to keep the security/privacy issue out of the
> introduction when we are motivating the protocol.  These are
> requirements that should (I believe, anyways) already be handled in
> the Discussion section of this document and in the requirements
> document.
>
>>
>> Section 1.3.1 Service Providers
>> This section is hard to understand without a hint on what kind of
>> information is provided by ALTO. I suggest to add a sentence including
>> abstracted network maps, asociated costs between the locations of the map or
>> specific properties or access costs to these locations.
>
> I'll see what we can do to add a small hint in here without going into detail.
>
>> - in 1st sentence: "... the peer selection process ... " ==> "peer" shoud be
>> replaced by "connection endpoints such as peers"
>
> Ack.
>
>>
>> Section 2.1 Terminology
>>
>> - in §2: the term "Endpoint" should be added
>> - a first section "2.1.X Endpoint" should be inserted before section 2.1.1
>> Endpoint Address to better introduce Endpoint Adress and Network Location
>> mentioning "Endpoint" with no prior definition.
>
> Ack - we'll add this.
>
>> Section 2.2 ALTO Service and Protocol Scope
>> - §3 "... The ALTO Information provided by the ALTO Server can be updated
>> dynamically based on network conditions ...": a sentence would be good here
>> to recall that ALTO does by no means replace real time network performance
>> measurement services.
>
> Do you instead mean ~real-time congestion control protocols?  If so,
> we can add a reminder.
>
>>
>> Section 3 Protocol Structure
>> - §3 3rd sentence "ALTO-Core provides the Map Service, which provides the
>> core ALTO informtion to
>> clients". The term "ALTO-Core" should be introduced ans besides it does not
>> appear again in the document.
>
> Actually, I think the term can just be dropped at this point. (Let me
> know if anyone disagrees)
>
>> Also replace "informtion" ==> "information".
>
> Ack.
>
>>
>>
>> Section 4 Network Map
>> - §2: "The Network Location endpoint property": i suggest "The Network
>> Location Endpoint Property"
>>
>>
>> Section 7.2.1 Discovering Information Resources
>> - §1 "To discover available resources, an ALTO Client may request the
>> Information Resource Directory": what are other means? There seem to be a
>> contradiction with Section 6.2 Protocol design where item "o Information
>> Resource Directory" says that "This directory is the single entry point to
>> an ALTO Service."
>
> Does changing it from
>  "an ALTO Client may request ... "
> to
>  "an ALTO Client requests... "
> clear this up?
>
>>
>> Section 7.2.7 Parsing
>> - last sentence "ALTO implementations MUST ignore...": i suggest an
>> insertion: "base protocol ALTO implementations MUST ignore...", or if it has
>> been previously defined, the term "ALTO-core" could be used here.
>
> The advice is common to any ALTO implementation, even one that is
> supporting an extension.  If an implementation is supporting an
> extension, then those fields are no longer "unknown".
>
> If that still isn't clear, do you have an alternate suggestion on the wording?
>
>>
>> Section 7.4 ALTO Errors
>> - §3 2nd sentence: "... information about the why a particular ...": i
>> suggest to remove "the" => "... information about why a particular ..."
>
> Ack - thanks.
>
>> Section 7.4.1 Media Type
>> "... The media type for an Error Resource ...": does it mean "The media type
>> for an ALTO Error Resource" ?
>>
>
> Yes - we'll make that more precise.
>
>>
>> Section 7.4.2
>> - 1st sentence "An Error Resource has the format:": is the answer to my
>> previous question is yes, then "An ALTO ALTO Error Resource has the format:"
>> reads easier.
>>
>
> Ack - I'll just avoid the extra 'ALTO' when updating the text :)
>
>>
>> Section 7.4.3 Error Codes
>> - §2 last sentence: "... Table 1in the HTTP response." : blank space is
>> needed after "1" ==> "... Table 1 in the HTTP response."
>>
>
> Ack.
>
>>
>> Section 7.6.2 Encoding
>> - §3 1st sentence "Any URI ... the format of an Information Resource
>> Directory.": i suggest to append "request" ==> "Any URI ... the format of an
>> Information Resource Directory request."
>
> Ack.
>
>> - §4 - item "capabilities": i didin't understand the sentence "or assume its
>> default value", although the protocol is not expected to guide the ALTO
>> Client's behavior.
>
> Each capability should have a default value documented in this
> specification - the text here is only indicating that the client
> should fall back to that value.  Does that answer the question?
>
> Note to self: "empty array" -> "empty object" in this paragraph
>
>>
>>
>> Section 7.6.3 Example
>>
>> In the first IRD example the last URI called
>> "http://alto.example.com/endpointcost/lookup" includes the following
>> capabilities:
>>
>> "cost-modes" : [ "ordinal", "numerical" ],
>> "cost-types" : [ "routingcost", "hopcount" ]
>>
>> In the second example listing URIs available in a subdomain, we have the
>> same capabilities for the URI called
>> "http://custom.alto.example.com/costmap/filtered"
>>
>> There is a need for the ALTO Server to disambiguate this encoding. As an
>> ALTO client, I don't know how to figure what Cost Mode is applied
>> respectively to the Cost Type "routingcost" and "hopcount". Is it both modes
>> for each cost type?
>>
>>
>> Also, as a server, how do I encode that for example "routingcost" is
>> available in both "ordinal" and "numerical" modes and "hopcount" in
>> "numerical" only? I guess separate URIs would be the way...
>
> Section 7.7.1.2.4. says:
>   An ALTO Server MUST support all of the Cost Types listed here for
>   each of the listed Cost Modes.  Note that an ALTO Server may provide
>   multiple Cost Map Information Resources, each with different
>   capabilities.
>
> Does that answer both questions?
>
>> Section 7.7.1.2.4 Capabilities
>>
>> - Object CostMapCapability has member "CostType cost-types<0..*>;". the
>> description says: "If not present, this member MUST be interpreted as an
>> empty array." On the other hand, Section 7.7.1.2 Cost Map in its §1 says
>> "This resource MUST be provided for at least the ’routingcost’ Cost Type and
>> ’numerical’ Cost Mode."
>> So would "CostType cost-types<1..*>" be more consistent?
>> Likewise, as the 'numerical' mode MUST be available, why not have CostMode
>> cost-modes<1..*> ?
>
> There are valid cases for them being empty. Specifically, this can
> happen if the server generating the Information Resource Directory is
> not authoritative as to what capabilities are supported.  See 7.6.3
> for an example.
>
> Each cost-map endpoint need not support the routingcost type - an ALTO
> Service must do so.
>
>> See also §7.7.3.1.3 Input Parameters, where encoding "EndpointProperty
>> properties<1..*>" is used, because 'pid' MUST be available.
>
> Do you mean "EndpointProperty prop-types<0..*>;" instead?
>
> This has a similar reasoning to the above for cost maps.
>
>> Section 7.7.2.2.3 Input Parameters
>> - item "constraints" use term "numerical cost". Onthe other hand, Section
>> 7.7.2.4.4 Capabilities in its item "cost-constraints" says (last sentence)
>> "... constraints may not have the intended effect for cost maps with the
>> ’ordinal’ Cost Mode... ".
>> Although it intuitively make more sens to have constraints on numerical
>> values, one may imagine that for some reasons an application clien may look
>> for alternative paths that have a poorer rank but not worse that a given
>> value and accordingly encode a constraint on 'ordinal' costs.
>> Therefore, I suggest to use term "cost value" instead of "numerical cost".
>
> Agree. that should not explicitly mention numerical costs in the
> documentation for constraints.  Good catch.
>
>> Section 7.7.3.1.3 Input Parameters
>> - §1 2nd sentence: "... data format of input parameteres...": typo ==> "...
>> data format of input parameters..."
>> - item "properties": "List of endpoint properties to returned... " i suggest
>> "List of endpoint properties to be returned... ".
>
> Ack.
>
>> I also suggest to add that
>> property 'pid' MUST be provided.
>
> That is already noted in 7.7.3.1 right?  Note that a particular URI
> need not provide the 'pid' property - the ALTO Service as a whole
> needs to do so.
>
> This seems worth clarifying - I'll add a note to do that.
>
>>
>>
>> Section 7.7.3.1.4 Capabilities
>> - object "EndpointPropertyCapability;" has a member "EndpointProperty
>> prop-types<0..*>". As 'pid' MUST be provided why not encode as
>> "EndpointProperty prop-types<1..*>" ?
>
> Same as the response above, I believe.
>
>>
>>
>>
>> -----------------------------------------------------
>> NITS
>> -----------------------------------------------------
>>
>> Abstract
>> - §3: ".... be provided by the network ..." => I suggest ".... be provided
>> by the network operator ..." or any applicable term
>>
>>
>> Section 1.1 Background and Problem Statement
>> - 2nd sentence "... about the network ..." => I suggest "... about the
>> network infrastructure ..."
>>
>>
>> Section 2.1 Terminology
>> - the typography should be harmonized between "endpoint address" and
>> "Endpoint Address".
>>
>> Section 2.2 ALTO Service and Protocol Scope
>>
>> - §1 last sentence: "... deployment scenario and discovery mechanism ..."
>> ==> I suggest to complete as follows "... ALTO deployment scenario and ALTO
>> service discovery mechanism ..."
>> - §2 1st sentence: "... the overall system architecture ..." ==> I suggest
>> "the overall ALTO system architecture"
>> - §4 last sentence: "... figure for completeness but outside ..." ==> I
>> suggest "... figure for completeness but are outside ..."
>>
>>
>> Section 3 Protocol Structure
>> - §3: i suggest to replace "functionality" by "functionalities"
>>
>>
>> Section 3.1.1 Map Service
>> - §1: replace "endpoints" by "Endpoints"
>>
>>
>> Section 7.4 ALTO Errors
>> - §3 2nd sentence: "... information about the why a particular ...": i
>> suggest to remove "the" => "... information about why a particular ..."
>>
>
> Ack.
>
> Thanks!
> Rich
>
>>
>>
>> Enrico Marocco a écrit :
>>
>>> The chairs would like to declare a Working Group Last Call for
>>> draft-ietf-alto-protocol-11, ending Friday May 11th.
>>>
>>> Please do review the latest version of the draft, and send any comments
>>> to the list before the expiry of WGLC so we can get this document ready
>>> for the IESG.
>>>
>>>
>>
>>
>> _______________________________________________
>> alto mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/alto