Application-Layer Traffic Optimization (ALTO) Problem Statement
RFC 5693

Received changes through RFC Editor sync (changed abstract to 'Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.

This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection. This memo provides information for the Internet community.')

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

[Ballot discuss]
[Updated to add a comment]

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.

As Lars has noted in his comment, this paragraph does not not accurately describe
the approach. ALTO is about sharing topology-related information with P2P peers, and
not about delegation of functions.

The important point that the authors may be alluding to is the introduction of new
trusted parties (the ALTO server) into the peer selection process.  In some cases,
such as an ALTO service offered by the network operator, the peer already has a business
relationship with the peer.  Where a third party offers this service, this may entail new
relationships for network operators and the peer.  Managing and authenticating these trust
relationships is likely to create new security requirements for all parties.

[Ballot comment]
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.

[Ballot discuss]
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.

As Lars has noted in his comment, this paragraph does not not accurately describe
the approach. ALTO is about sharing topology-related information with P2P peers, and
not about delegation of functions.

The important point that the authors may be alluding to is the introduction of new
trusted parties (the ALTO server) into the peer selection process.  In some cases,
such as an ALTO service offered by the network operator, the peer already has a business
relationship with the peer.  Where a third party offers this service, this may entail new
relationships for network operators and the peer.  Managing and authenticating these trust
relationships is likely to create new security requirements for all parties.

[Ballot discuss]
This is a much needed document and I support its publication.
There was one aspect missing from the document and I believe it
would be important to note that before moving forward.

Specifically, the document casts the peer selection problem
as merely a network layer selection issue. However, this is
just one of the criteria from the perspective of, say, a P2P
application. It is also concerned with things like

- balancing load across participating nodes, not just load across
  network links, to avoid disturbing any individual user too much
- fetching a rare piece of a file before other parts, whether or not
  that piece is in a congested network part or not

And sometimes different factors can point to different "correct"
selections.

In short, I would like to see the document acknowledge that
network layer peer selection is just one of the factors that
a P2P node needs to consider when selecting peers.

Here's a suggested edit:


OLD:
Selection of a good host from
an overlay topological proximity has a large impact on the overall
traffic generated.
NEW:
Selection of a good host from
an overlay topological proximity has a large impact on the overall
traffic generated. Note that while topological considerations are
important, they are still just one factor among many for typical
applications. Applications also need to consider other issues, such
as avoiding overload of individual nodes, fetching rare pieces of
information before others, and so on. However, better information
about topological conditions improves the overall selection algorithm
on one important aspect.

[Ballot comment]
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."

[Ballot comment]
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.

Document:
Application-Layer Traffic Optimization (ALTO) Problem Statement
draft-ietf-alto-problem-statement-02
(Informational)

(1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Jon Peterson is the document shepherd. I have personally reviewed this
version of the document, and it is ready for forwarding to the IESG
for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has had reviews by key WG members as well as TSV
experts. Additionally, being the document that accompanied the
chartering of the ALTO WG, it has received extended review by the
whole IETF community during the WG creation process.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

None.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

None. No IPR disclosures.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

Strong consensus for publishing.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

None.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Checked with ID nits 2.11.11: no issues nor nits found.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document has only Informational references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

This document raises no actions for the IANA.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

There is no formal language in the document.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

        Technical Summary

Peer-to-peer applications, such as file sharing, real-time
communication, and live and on-demand media streaming use a
significant amount of Internet resources.  Such applications often
transfer large amounts of data in peer-to-peer connections.  However,
they usually have little knowledge of the underlying network topology.
As a result, they may choose their peers randomly with respect to the
underlying network topology or they may choose their peers based on
measurements and statistics that, in many situations, may lead to
suboptimal choices.  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.

        Working Group Summary

This document is the problem statement that accompained the chartering
process of the ALTO WG.

        Document Quality

The document has received extended review by WG members and TSV
experts.

Document:
Application-Layer Traffic Optimization (ALTO) Problem Statement
draft-ietf-alto-problem-statement-02
(Informational)

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Jon Peterson is the document shepherd. I have personally reviewed this
version of the document, and it is ready for forwarding to the IESG
for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had reviews by key WG members as well as TSV
experts. Additionally, being the document that accompanied the
chartering of the ALTO WG, it has received extended review by the
whole IETF community during the WG creation process.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

None.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

None. No IPR disclosures.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Strong consensus for publishing.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

None.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Checked with ID nits 2.11.11: no issues nor nits found.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document has only Informational references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

This document raises no actions for the IANA.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There is no formal language in the document.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

Peer-to-peer applications, such as file sharing, real-time
communication, and live and on-demand media streaming use a
significant amount of Internet resources. Such applications often
transfer large amounts of data in peer-to-peer connections. However,
they usually have little knowledge of the underlying network topology.
As a result, they may choose their peers randomly with respect to the
underlying network topology or they may choose their peers based on
measurements and statistics that, in many situations, may lead to
suboptimal choices. 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.

Working Group Summary

This document is the problem statement that accompained the chartering
process of the ALTO WG.

Document Quality

The document has received extended review by WG members and TSV
experts.