Application-Layer Traffic Optimization (ALTO) Problem Statement
draft-ietf-alto-problem-statement-04

Thanks for this document.

Possibly a bit of a terminology hicough...
In Section 1 you have:
> Peer-to-peer (P2P) applications, such as file sharing, real-time
> communication, and live and on-demand media streaming use a
> significant amount of Internet resources
But in Section 2
> Resource:  Content (such as a file or a chunk of a file), or a server
>   process (for example to relay a media stream or perform a
>   computation), which applications can access.  In the ALTO context,
>   a resource is often available in several equivalent replicas.  In
>   addition, different peers share these resources, often
>   simultaneously.

Maybe you can solve this by adding another term to Section 2 to 
define "Internet Resource."

I am confused by section 4.5 and by DHTs being listed as part of the use cases. I percieve DHTs as a piece of technology that allow running P2P applications, so while it may be true that 'An ALTO solution can provide valuable information for DHT algorithms' on the other hand ALTO also is based on DHTs in order ro run on a P2P overlay.

  This isn't a blocking discuss, but please give these comments some
  serious consideration. The document touches on lots of important
  points, but misses one issue which I consider to be of key importance:
  what kinds of information can and will be provided using ALTO. Right
  now, the document is very generic on this, talking about
  "network-layer information" that will enable "better-than-random
  selection" of peers. I'd very much like the document to become more
  concrete, and discuss what kinds of network-layer information could
  reasonably be provided by an ALTO box, what kinds could be provided
  but are useless (because the peers can obtain it as easily by
  themselves) and what kinds of infomation is out of scope (for example,
  because it changes on timescales that make it impossible to provide
  via an out-of-band service like ALTO).


INTRODUCTION, paragraph 14:
>    This document describes problems
>    related to improving traffic generated by peer-to-peer applications.
>    In particular, this document discusses issues which better-than-
>    random peer selection based on network-layer information may raise.

  Please be more clear in the abstract. This document discusses issues
  related to an information-sharing *service* to *enable* BTR peer
  selection; it's not about BTR selection or improving traffic itself
  (that will depend on whatever the applications using this service will
  do with the information.)


Section 1.1., paragraph 4:
>    Recent studies [ACM.ispp2p] [WWW.p4p.overview] [ACM.ono] show a
>    possible solution to this problem.  Internet Service Providers (ISP),
>    network operators or third parties can collect more reliable network
>    information.  This information includes relevant information such as
>    topology or bandwidth available. Normally, such information changes
>    on a much longer time scale than information used for congestion
>    control on the transport layer.

  "Bandwidth available" to a specific peer and congestion are
  intrinsically linked. It's not accurate to say that one changes on
  slower timescales than the other. "Bandwidth available" information is
  likely something that an ALTO box cannot provide with useful
  precision. I'd pick a different example here.


Section 1.1., paragraph 5:
>    This document gives the
>    problem statement of improving traffic generated by P2P applications
>    using information provided by a separate party.

  See my comment about the abstract. I believe that this paragraph
  doesn't quite capture what this document is about.


Section 2., paragraph 2:
>    Application:  A distributed communication system (e.g., file sharing)
>       that uses the ALTO service to improve its performance or quality
>       of experience while improving resource consumption in the
>       underlying network infrastructure.  Applications may use the P2P
>       model to organize themselves, use the client-server model, or use
>       a hybrid of both (i.e., a mixture between the P2P model and the
>       client-server model).

  Up until know, the document was all about P2P. Now the documents talks
  about including hybrid applications, which presumably can degenerate
  into traditional client/server behavior. Please be very clear what the
  scope of ALTO is, P2P only or also client/server. If the latter, you
  need to make this clear in the abstract and introduction.


Section 3., paragraph 1:
>    Network engineers have been facing the problem of traffic
>    optimization for a long time and have designed mechanisms like MPLS
>    [RFC3031] and DiffServ [RFC3260] to deal with it.  The problem these
>    protocols address consists in finding (or setting) optimal routes for
>    packets traveling between specific source and destination addresses
>    and based on requirements such as low latency, high reliability, and
>    priority.  Such solutions are usually implemented at the link and
>    network layers, and tend to be almost transparent.  At best,
>    applications can only "mark" the traffic they generate with the
>    corresponding properties.

  This paragraph is confused on what DiffServ is.


Section 3., paragraph 4:
>    Addressing the Application-Layer Traffic Optimization (ALTO) problem
>    means, on the one hand, deploying an ALTO service to provide
>    applications with information regarding the underlying network and,
>    on the other hand, enhancing applications in order to use such
>    information to perform better-than-random selection of the endpoints
>    they establish connections with.

  Again, please be clear about the scope. The ALTO WG is only chartered
  to look at some aspects of the former (providing a service to share
  network information - actually, only the query protocol towards that
  service). "Enhancing applications" (defining how applicaitons should
  or may use the information) is not in scope.


Section 6., paragraph 2:

>    The approach proposed in this document asks P2P applications to
>    delegate a portion of their routing capability to third parties.
>    This gives the third party a significant role in P2P systems.

  I think this paragraph is highly inaccurate. ALTO is about sharing
  topology-related information with P2P peers, and not about delegation
  of functions.

Figure 1 implies that the Application protocol (****) runs between a Peer and the Resource 
Directory.  Shouldn't the application protocol involve two Peers instead?