Application-Layer Traffic Optimization (ALTO) Problem Statement
RFC 5693
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-12-20
|
04 | (System) | 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 -- … 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.') |
2015-10-14
|
04 | (System) | Notify list changed from alto-chairs@ietf.org, jon.peterson@neustar.biz, draft-ietf-alto-problem-statement@ietf.org to jon.peterson@neustar.biz |
2012-08-22
|
04 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
2012-08-22
|
04 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2009-10-23
|
04 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2009-10-23
|
04 | Amy Vezza | [Note]: 'RFC 5693' added by Amy Vezza |
2009-10-22
|
04 | (System) | RFC published |
2009-09-21
|
04 | (System) | IANA Action state changed to No IC from In Progress |
2009-09-21
|
04 | (System) | IANA Action state changed to In Progress |
2009-09-21
|
04 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2009-09-18
|
04 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2009-09-18
|
04 | Cindy Morgan | IESG has approved the document |
2009-09-18
|
04 | Cindy Morgan | Closed "Approve" ballot |
2009-09-18
|
04 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2009-09-18
|
04 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2009-09-18
|
04 | (System) | New version available: draft-ietf-alto-problem-statement-04.txt |
2009-09-16
|
04 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko |
2009-09-15
|
04 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-09-15
|
03 | (System) | New version available: draft-ietf-alto-problem-statement-03.txt |
2009-09-11
|
04 | (System) | Removed from agenda for telechat - 2009-09-10 |
2009-09-10
|
04 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2009-09-10
|
04 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2009-09-10
|
04 | Tim Polk | [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 … [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? |
2009-09-10
|
04 | Tim Polk | [Ballot discuss] [Updated to add a comment] Section 6., paragraph 2: > The approach proposed in this document asks P2P applications to > … [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. |
2009-09-10
|
04 | Dan Romascanu | [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 … [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. |
2009-09-10
|
04 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2009-09-10
|
04 | Tim Polk | [Ballot discuss] Section 6., paragraph 2: > The approach proposed in this document asks P2P applications to > delegate a portion of their … [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. |
2009-09-10
|
04 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2009-09-10
|
04 | Jari Arkko | [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 … [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. |
2009-09-10
|
04 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2009-09-10
|
04 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2009-09-09
|
04 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
2009-09-09
|
04 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2009-09-09
|
04 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica |
2009-09-09
|
04 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2009-09-09
|
04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2009-09-09
|
04 | Adrian Farrel | [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 … [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." |
2009-09-08
|
04 | Lars Eggert | [Ballot comment] This isn't a blocking discuss, but please give these comments some serious consideration. The document touches on lots of important points, … [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. |
2009-09-08
|
04 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2009-09-05
|
04 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded by Alexey Melnikov |
2009-09-03
|
04 | Lisa Dusseault | Placed on agenda for telechat - 2009-09-10 by Lisa Dusseault |
2009-09-03
|
04 | Lisa Dusseault | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lisa Dusseault |
2009-09-03
|
04 | Lisa Dusseault | [Ballot Position Update] New position, Yes, has been recorded for Lisa Dusseault |
2009-09-03
|
04 | Lisa Dusseault | Ballot has been issued by Lisa Dusseault |
2009-09-03
|
04 | Lisa Dusseault | Created "Approve" ballot |
2009-08-04
|
04 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-08-03
|
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2009-08-03
|
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2009-07-27
|
04 | Amanda Baber | IANA comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2009-07-21
|
04 | Cindy Morgan | Last call sent |
2009-07-21
|
04 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
2009-07-21
|
04 | Lisa Dusseault | 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 … 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. |
2009-07-21
|
04 | Lisa Dusseault | State Change Notice email list have been change to alto-chairs@tools.ietf.org, jon.peterson@neustar.biz, draft-ietf-alto-problem-statement@tools.ietf.org from alto-chairs@tools.ietf.org, draft-ietf-alto-problem-statement@tools.ietf.org |
2009-07-21
|
04 | Lisa Dusseault | Last Call was requested by Lisa Dusseault |
2009-07-21
|
04 | Lisa Dusseault | State Changes to Last Call Requested from Publication Requested by Lisa Dusseault |
2009-07-21
|
04 | (System) | Ballot writeup text was added |
2009-07-21
|
04 | (System) | Last call text was added |
2009-07-21
|
04 | (System) | Ballot approval text was added |
2009-07-14
|
04 | Cindy Morgan | [Note]: 'Jon Peterson (jon.peterson@neustar.biz) is the document shepherd.' added by Cindy Morgan |
2009-07-14
|
04 | Cindy Morgan | 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 … 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. |
2009-07-14
|
04 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2009-07-03
|
02 | (System) | New version available: draft-ietf-alto-problem-statement-02.txt |
2009-05-26
|
01 | (System) | New version available: draft-ietf-alto-problem-statement-01.txt |
2009-04-21
|
00 | (System) | New version available: draft-ietf-alto-problem-statement-00.txt |