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

[Sabine Randriamasy <[e-mail]>]

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.

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?

-----------------------------------------------------
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.
- §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.
- §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?


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.

- in 1st sentence: "... the peer selection process ... " ==> "peer" 
shoud be replaced by "connection endpoints such as peers"


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.


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.


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.
Also replace "informtion" ==> "information".


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."


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.


Section 7.4 ALTO Errors
- §3 2nd sentence: "... information about the why a particular ...": i 
suggest to remove "the" => "... information about why a particular ..."


Section 7.4.1 Media Type
"... The media type for an Error Resource ...": does it mean "The media 
type for an ALTO Error Resource" ?


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.


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."


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."
- §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.



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 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..*> ?
See also §7.7.3.1.3 Input Parameters, where encoding "EndpointProperty 
properties<1..*>" is used, because 'pid' MUST be available.


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".


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... ". I also suggest 
to add that property 'pid' MUST be provided.


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..*>" ?



-----------------------------------------------------
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 ..."



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.
>
>