idnits 2.17.1 draft-marocco-alto-problem-statement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 394. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 15, 2008) is 5856 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Marocco 3 Internet-Draft Telecom Italia 4 Intended status: Informational V. Gurbani 5 Expires: October 17, 2008 Bell Laboratories, Alcatel-Lucent 6 April 15, 2008 8 Application-Layer Traffic Optimization (ALTO) Problem Statement 9 draft-marocco-alto-problem-statement-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 17, 2008. 36 Abstract 38 A significant part of the Internet traffic today is generated by 39 peer-to-peer applications used for file sharing, realtime 40 communications and live media streaming. Such applications often 41 deal with large amounts of data in direct peer-to-peer connections, 42 but they usually have little knowledge of the underlying topology, 43 both at the overlay layer and the network layer. As a result, they 44 may choose their peers based on measurements and statistics which, in 45 some specific situations, often lead to suboptimal choices. This 46 document describes problems related to optimizing traffic generated 47 by peer-to-peer applications through the use of link and network 48 layer information. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Research or Engineering? . . . . . . . . . . . . . . . . . 4 54 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1.1. Information Distribution . . . . . . . . . . . . . . . 5 57 2.1.2. Topology Hiding . . . . . . . . . . . . . . . . . . . 5 58 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. File sharing . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Live media streaming . . . . . . . . . . . . . . . . . . . 6 61 3.3. Realtime communications . . . . . . . . . . . . . . . . . 6 62 3.4. Distributed Hash Tables . . . . . . . . . . . . . . . . . 6 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Informative References . . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 A significant part of the Internet traffic is today generated by 72 peer-to-peer (P2P) applications used for file sharing, realtime 73 communications and live media streaming [WWW.cachelogic.picture] 74 [WWW.wired.fuel]. Contrary to client/server architectures, P2P 75 applications access resources (e.g. files or media relays) 76 distributed across the Internet and exchange large amounts of data in 77 connections that they establish directly with nodes hosting such 78 resources. 80 One of the advantages of P2P systems comes from the fact that the 81 resources they offer are often made available through multiple 82 instances. Yet, applications generally ignore the topology of the 83 latent overlay network and have to select among available instances 84 based on information they deduce from empirical measurements which, 85 in some particular situations, could lead to suboptimal choices. 87 For example, popular metrics based on round trip time estimation 88 perform quite badly for file sharing applications, as they tend to 89 ignore bandwidth and reliability of underlying links, which have 90 much more influence than delay on file transfers. 92 Many of the existing overlay networks are built on top of connections 93 between peers that are established regardless of the underlying 94 network topology. In addition to simply achieving suboptimal 95 performance, such networks can lead to congestions and cause serious 96 inefficiencies. As shown in [ACM.fear], traffic generated by popular 97 P2P applications often cross network boundaries multiple times, 98 overloading links which are frequently subject to congestion 99 [ACM.bottleneck]. 101 Recent studies [ACM.ispp2p] [WWW.p4p.overview] have shown that if 102 Internet Service Providers (ISP) and network operators provide 103 topology and/or bandwidth information to P2P applications, it would 104 be possible to greatly increase aplication performance, reduce 105 congestions and optimize the overall traffic across different 106 networks. 108 This document describes the problem of optimizing traffic generated 109 by P2P applications using information provided by ISPs and network 110 operators. Section 2 introduces the problem and the main issues to 111 keep in mind when designing a solution, while Section 3 describes 112 some use cases where both P2P users and network operators would 113 benefit from such a solution. 115 1.1. Research or Engineering? 117 At the time of writing, several solutions have been proposed to 118 address the problem described in this document, both inside and 119 outside the IETF [I-D.bonaventure-informed-path-selection] 120 [ACM.ispp2p] [WWW.p4p.overview], all accompained by encouraging 121 simulation and field test results. Such solutions have been proposed 122 independently, but all consists of two essential parts: 123 o a discovery mechanism which can be used by a P2P application to 124 find a reliable information source; 125 o a protocol used by P2P applications to query such sources in order 126 to retrieve the information needed to choose the best endpoint 127 among those which host a desired resource. 129 It is not easy to foresee how such solutions would perform in the 130 Internet, but a more accurate evaluation would require representative 131 data collected from real systems by a critical mass of users. 133 However, wide adoption will probably never happen without an 134 agreement on a common solution based on open standards; whether such 135 a solution should be still studied as a research problem, published 136 as a "Proposed Standard" or an "Experimental" RFC [RFC2026] is an 137 open issue. 139 2. The Problem 141 Network engineers have been facing the problem of traffic 142 optimization for a long time now and have already designed mechanisms 143 like MPLS [RFC3031] and DiffServ [RFC3260] to deal with it. The 144 problem they address consists in finding (or setting) an optimal 145 route for packets travelling between specific source and destination 146 addresses and based on requirements such as low latency, high 147 reliability, and priority. Such solutions are usually implemented at 148 the link and network layers, and tend to be almost transparent. 149 Applications only need to "mark" the traffic they generate with the 150 corresponding properties. 152 However, P2P applications which are today posing serious challenges 153 to Internet infrastructures, do not benefit much from the above 154 techniques and "cooperating" with network operators could greatly 155 optimize the traffic they generate. In fact, when a P2P application 156 needs to establish a connection, the logical target is not a host, 157 but rather a resource (e.g. a file or a media relay) generally 158 available in multiple instances on different hosts; selection of the 159 closest one -- or, in general, the best from an overlay topological 160 proximity -- has much more impact on the overall traffic than the 161 route followed by its packets to reach the endpoint. 163 Addressing the Application-Layer Traffic Optimization (ALTO) problem 164 means, on the one hand, providing topology information regarding the 165 underlying network and, on the other hand, enhancing P2P applications 166 in order to use such information to select the best endpoints among 167 those that are available for the connections they are going to 168 establish. 170 2.1. Issues 172 2.1.1. Information Distribution 174 As a direct consequence of the total distribution of the Internet, it 175 seems almost impossible to centralize all information P2P 176 applications may need to optimize traffic they generate. It is quite 177 likely that such information would be distributed at an ISP or domain 178 level. It is also reasonable to expect that these same network 179 administrators will control provision of such information. 181 However, as applications usually have no knowledge of the 182 administrative entities running the network they are using, any 183 solution will need to define a discovery mechanism (e.g. based on or 184 similar to reverse DNS [RFC2317]) and perhaps an authority to certify 185 information sources. 187 2.1.2. Topology Hiding 189 Operators generally consider topology of the networks they control to 190 be confidential information; therefore, in order to succeed and 191 achieve wide adoption, any solution will need to help P2P 192 applications to always choose best peers without explicitly 193 disclosing topology of the underlying network. 195 3. Use Cases 197 3.1. File sharing 199 File sharing applications allow users to search for content shared by 200 other users and download it. Typically, search results consist of 201 many istances of the same file available from multiple sources; the 202 goal of an ALTO solution would be to help peers find the best ones 203 according to the underlying networks. 205 On the application side, integration of ALTO functionalities may 206 happen at different levels. For example, while in the completely 207 decentralized Gnutella network selection of the best sources is 208 totally up to the user, in systems like BitTorrent and eDonkey, 209 central elements (i.e. trackers or servers) act as mediators. 211 Therefore, in the former case, optimization would require 212 modification in the applications, while in the latter it could just 213 be implemented in some central elements. 215 3.2. Live media streaming 217 P2P applications for live streaming allow users to receive multimedia 218 content produced by one source and targeted to multiple destinations, 219 in a realtime or near-realtime way without recurring to multicast. 220 Such applications tipically participate in the distribution of the 221 content, acting as both receivers and senders; the goal of an ALTO 222 sulution would be to help peers to find the best sources and the best 223 destinations for media flows they receive and relay. 225 3.3. Realtime communications 227 P2P realtime communications allow users to establish direct media 228 flows, usually to place audio and video calls, or to have text chats. 229 In the basic case, media would flow directly between the two 230 endpoints; however, in the general case, a significant portion of 231 communications between users with limited access to the Internet 232 (e.g. users behind NATs, firewalls or HTTP proxies) need to be 233 relayed by other elements. Such media relays are distributed over 234 the Internet -- in some cases co-located with applications with a 235 public address; the goal of an ALTO solution would be to help peers 236 to find the best relays. 238 3.4. Distributed Hash Tables 240 Distributed hash tables (DHT) are a class of overlay algorithms used 241 to implement lookup functionalities in popular P2P systems, without 242 recurring to centralized elements. In such systems, peers maintain 243 addresses of other peers participating in the same DHT in a routing 244 table, sorted according to specific criteria. An ALTO solution would 245 provide valuable information for DHT algorithms which, in order to 246 reduce path latency of distributed queries, include round trip time 247 estimations among such criteria [SIGCOMM.resprox]. 249 4. Security Considerations 251 The approach proposed in this document requires P2P applications to 252 delegate a portion of their routing capability to network operators, 253 giving them a significant role in systems that they often view 254 unfavorably. 256 It is conceivable that the P2P network would consider operator 257 intervention to be hostile because the operator could, for example: 259 o redirect applications to corrupted mediators providing malicious 260 content; 261 o track connections to perform content inspection; 262 o apply policies based on criteria other than network efficiency 263 (for example, to avoid peering points regulated by inconvenient 264 economic agreements). 266 However, ALTO is completely optional for P2P applications and its 267 purpose is to help improve performance of such applications. If, for 268 some reason, it fails to achieve this purpose, it would simply fail 269 to gain popularity and would not be used. 271 Even in cases where providers would decide to maliciously alter 272 results returned by ALTO queries only after the solution has gained 273 popularity (i.e. they behave for a while until it becomes popular and 274 then they start misbehaving), it would be fairly easy for P2P 275 application maintainers and users to revert to solutions that are not 276 using it. After all, it would all come down to change some 277 application settings in cases where the protocol is implemented 278 inside the client and upgrading centralized elements for 279 architectures like BitTorrent and eDonkey. 281 5. Acknowledgments 283 We have to acknowledge many people. For the record: Vinay Aggarwal 284 and the P4P working group for the research work done outside the 285 IETF. Emil Ivov and Rohan Mahy for comments and corrections. 287 6. Informative References 289 [ACM.bottleneck] 290 Akella, A., Seshan, S., and A. Shaikh, "An Empirical 291 Evaluation of WideArea Internet Bottlenecks". 293 [ACM.fear] 294 Karagiannis, T., Rodriguez, P., and K. Papagiannaki, 295 "Should ISPs fear fear Peer-Assisted Content 296 Distribution?". 298 [ACM.ispp2p] 299 Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs 300 and P2P systems co-operate for improved performance?". 302 [I-D.bonaventure-informed-path-selection] 303 Saucez, D. and B. Donnet, "The case for an informed path 304 selection service", 305 draft-bonaventure-informed-path-selection-00 (work in 306 progress), February 2008. 308 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 309 3", BCP 9, RFC 2026, October 1996. 311 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 312 ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. 314 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 315 Label Switching Architecture", RFC 3031, January 2001. 317 [RFC3260] Grossman, D., "New Terminology and Clarifications for 318 Diffserv", RFC 3260, April 2002. 320 [SIGCOMM.resprox] 321 Gummadi, K., Gummadi, R., Ratnasamy, S., Gribble, S., 322 Shenker, S., and I. Stoica, "The impact of DHT routing 323 geometry on resilience and proximity". 325 [WWW.cachelogic.picture] 326 Parker, A., "The true picture of peer-to-peer 327 filesharing", . 329 [WWW.p4p.overview] 330 Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang, 331 "P4P: Explicit Communications for Cooperative Control 332 Between P2P and Network Providers", 333 . 335 [WWW.wired.fuel] 336 Glasner, J., "P2P fuels global bandwidth binge", 337 . 339 Authors' Addresses 341 Enrico Marocco 342 Telecom Italia 343 Via G. Reiss Romoli, 274 344 Turin 10148 345 Italy 347 Email: enrico.marocco@telecomitalia.it 348 Vijay K. Gurbani 349 Bell Laboratories, Alcatel-Lucent 350 2701 Lucent Lane 351 Lisle, IL 60532 352 USA 354 Email: vkg@alcatel-lucent.com 356 Full Copyright Statement 358 Copyright (C) The IETF Trust (2008). 360 This document is subject to the rights, licenses and restrictions 361 contained in BCP 78, and except as set forth therein, the authors 362 retain all their rights. 364 This document and the information contained herein are provided on an 365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 366 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 367 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 368 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 369 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 372 Intellectual Property 374 The IETF takes no position regarding the validity or scope of any 375 Intellectual Property Rights or other rights that might be claimed to 376 pertain to the implementation or use of the technology described in 377 this document or the extent to which any license under such rights 378 might or might not be available; nor does it represent that it has 379 made any independent effort to identify any such rights. Information 380 on the procedures with respect to rights in RFC documents can be 381 found in BCP 78 and BCP 79. 383 Copies of IPR disclosures made to the IETF Secretariat and any 384 assurances of licenses to be made available, or the result of an 385 attempt made to obtain a general license or permission for the use of 386 such proprietary rights by implementers or users of this 387 specification can be obtained from the IETF on-line IPR repository at 388 http://www.ietf.org/ipr. 390 The IETF invites any interested party to bring to its attention any 391 copyrights, patents or patent applications, or other proprietary 392 rights that may cover technology that may be required to implement 393 this standard. Please address the information to the IETF at 394 ietf-ipr@ietf.org.