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

[Sabine Randriamasy <[e-mail]>]

Hi Rich,


Richard Alimi a écrit :
> 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?
>   
I remember there was a discussion on the list and also in Quebec that 
was on specifying the features that the ALTO MUST have. My question here 
was rather on the possibility listing the MUST identified in the doc. I 
don't have any reference of RFC doing this and as it may generate 
duplicate information then it seems preferable not to do it.
>   
>> -----------------------------------------------------
>> 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.
>   
Yes, thanks
>   
>> - §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?
>   
I'd say both and other related such as *ClosestNode.com or others 
examples you may have in mind.
*
>   
>> - §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.
>   
Ok
>   
>> 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.
>   
Sure. It's just that 2 or 3 lines with basic Alto services would make 
the reading more comfortable.
>   
>> - 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.
>   
yes, sorry for the confusing phrasing.
>   
>> 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)
>   
Ok
>   
>> 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?
>   
yes
>   
>> 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".
>   
Ok
> If that still isn't clear, do you have an alternate suggestion on the wording?
>   
We can leave the initial sentence
>   
>> 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 :)
>   
Ok :-)
>   
>> 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?
>   
Yes. Then how about saying "or assume its default value that SHOULD be 
documented in this specification"
> 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?
>   
If the conclusion of this text for the example IRD is that 'routingcost' 
and 'hopcount' are each available for both 'numerical' and 'ordinal' 
mode, then, as § 7.7.1.2.4 comes after the IRD example, I think that 
things would be completely clear if § 7.6.3 would include an 
illustrative sentence like, "In this example, the ALTO server provides 
the Endpoint Cost Service for Cost Types 'routingcost' and 'hopcount', 
each available for both 'numerical' and 'ordinal' mode".

As for my 2nd question, I understand that for the mentionned case, the 
IRD then must include 2 URIs: one for 'routingcost' and the other for 
'hopcount'.
>   
>> 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.
>   
Ok
> Each cost-map endpoint need not support the routingcost type - an ALTO
> Service must do so.
>   
Ok
>   
>> 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?
>   
Yes, the error is on my side, there was a confusion with §7.7.3.1.4 
Capabilities.
> This has a similar reasoning to the above for cost maps.
>   
Ok
>   
>> 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.
>   
Thanks
>   
>> 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.
>   
Yes, again, my confusion.
>   
>> -----------------------------------------------------
>> 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
>>