idnits 2.17.1 draft-kiesel-alto-reqs-01.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 407. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 431. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (November 3, 2008) is 5647 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-marocco-alto-problem-statement-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kiesel, Ed. 3 Internet-Draft NEC 4 Intended status: Informational L. Popkin 5 Expires: May 7, 2009 Pando Networks, Inc. 6 S. Previdi 7 Cisco Systems, Inc. 8 R. Woundy 9 Comcast Corporation 10 Y R. Yang 11 Yale University 12 November 3, 2008 14 Application-Layer Traffic Optimization (ALTO) Requirements 15 draft-kiesel-alto-reqs-01.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on May 7, 2009. 42 Abstract 44 Many Internet applications are used to access resources, such as 45 pieces of information or server processes, which are available in 46 several equivalent replicas on different hosts. This includes, but 47 is not limited to, peer-to-peer file sharing applications. The goal 48 of Application-Layer Traffic Optimization (ALTO) is to provide 49 guidance to applications, which have to select one or several hosts 50 from a set of candidates, that are able to provide a desired 51 resource. These recommendations shall be based on parameters that 52 affect performance and efficiency of the data transmission between 53 the hosts, e.g., the topological distance. The ultimate goal is to 54 improve performance (or Quality of Experience) in the application 55 while reducing resource consumption in the underlying network 56 infrastructure. 58 This document enumerates an initial set of requirements for ALTO and 59 solicits feedback and discussion. 61 Table of Contents 63 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. ALTO Terminology and Entities . . . . . . . . . . . . . . . . 6 66 4. ALTO Requirements . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. ALTO Interface . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. Error handling and overload protection for ALTO . . . . . 7 69 4.3. Security and Privacy . . . . . . . . . . . . . . . . . . . 9 70 5. Example rating criteria . . . . . . . . . . . . . . . . . . . 10 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 76 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 14 77 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 79 Intellectual Property and Copyright Statements . . . . . . . . . . 17 81 1. Requirements notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Introduction 89 The motivation for Application-Layer Traffic Optimization (ALTO) is 90 described in the ALTO problem statement: 92 "A significant part of the Internet traffic today is generated by 93 peer-to-peer applications used, for example, for file sharing, 94 realtime communications and live media streaming. Such applications 95 often deal with large amounts of data in direct peer-to-peer 96 connections, but they usually have little knowledge of the underlying 97 network topology. As a result, they may choose their peers based on 98 measurements and statistics which, in some situations, may lead to 99 suboptimal choices." [I-D.marocco-alto-problem-statement]. 101 The goal of ALTO is to provide information which can help peer-to- 102 peer (P2P) applications to make better decisions with respect to peer 103 selection. However, ALTO may be useful for non-P2P applications as 104 well. For example, clients of client-server applications may use 105 information provided by ALTO to select one of several servers or 106 information replicas. As another example, ALTO information could be 107 used to select a media relay needed for NAT traversal. The goal of 108 these informed decisions is to improve performance (or Quality of 109 Experience) in the application while reducing resource consumption in 110 the underlying network infrastructure. 112 Usually, it would be difficult or even impossible for application 113 entities to acquire this information by other mechanisms (e.g., using 114 measurements between the peers of a P2P overlay), because of 115 complexity or because it is based on network topology information, 116 network operational costs, or network policies, which the respective 117 network provider does not want to disclose in detail. 119 The logical entities that provide the ALTO service do not take part 120 in the actual user data transport, i.e., they do not implement 121 functions for relaying user data. They may be placed on various 122 kinds of physical nodes, e.g., on dedicated servers, as auxiliary 123 processes in routers, on "super peers" of a P2P application operated 124 by the network provider, etc. 126 3. ALTO Terminology and Entities 128 This document uses the following ALTO-related terms, which are 129 defined in [I-D.marocco-alto-problem-statement]: 131 Application, Overlay Network, Peer, Resource, Resource Identifier, 132 Resource Provider, Resource Consumer, Resource Directory, Transport 133 Address, Host Location Attribute, ALTO Service, ALTO Server, ALTO 134 Client, ALTO Query, ALTO Reply, ALTO Transaction, Local Traffic, 135 Peering Traffic, Transit Traffic. 137 4. ALTO Requirements 139 4.1. ALTO Interface 141 REQ. 1: The ALTO service MUST implement one or several well-defined 142 interfaces, which can be queried from ALTO clients. 144 REQ. 2: The ALTO clients MUST be able to query information from the 145 ALTO service, which provides guidance for selecting appropriate 146 resource providers. 148 REQ. 3: ALTO clients MUST be able to find out where to send ALTO 149 queries. 151 REQ. 4: One mode of ALTO operation is that ALTO clients may be 152 embedded directly in the resource consumer (e.g., peer of an 153 unstructured P2P application), which wants to access a resource. 155 However, another mode of operation is to perform ALTO queries 156 indirectly, via resource directories. These translate a resource 157 identifier to a list of resource providers with their corresponding 158 transport addresses. The resource directories may issue ALTO queries 159 to solicit preference on such lists, considering the respective 160 resource consumer. 162 The ALTO protocol MUST support both modes of operation. One way to 163 fulfill this requirement is to include in the ALTO query a a host 164 location attribute of the resource consumer, i.e., the entity that 165 will eventually perform the data transfer. 167 REQ. 5: The syntax and semantics of the ALTO protocol MUST be 168 extensible to allow the requirements of future applications to be 169 adopted. This includes, amongst others, support for adding protocol 170 extensions in a non-disruptive, backward-compatible way, as well as 171 protocol versioning support to clearly distinguish between 172 incompatible major versions of the protocol. 174 REQ. 6: The information available from the ALTO service is not a 175 replacement for congestion control mechanisms. Applications using 176 ALTO MUST ensure that they do not cause congestion in the network, 177 e.g., by using TCP transport, which includes congestion control 178 mechanisms. 180 4.2. Error handling and overload protection for ALTO 182 REQ. 7: Any application designed to use ALTO MUST also work 183 reasonably if no ALTO servers can be found or if no responses to ALTO 184 queries are received, e.g., due to connectivity problems or overload 185 situation. 187 REQ. 8: An overloaded ALTO server receiving too many requests MAY 188 silently discard excess requests. 190 REQ. 9: An ALTO client MAY retransmit an unanswered ALTO query after 191 a reasonable amount of time, or it MAY query a different server. 192 Otherwise, or if all retransmissions or queries to different servers 193 have failed as well, the ALTO client MUST report to the application 194 that no ALTO information is available. In this case, the application 195 has to perform the resource provider selection without ALTO guidance. 197 REQ. 10: An ALTO client MUST limit the total number of unanswered 198 ALTO queries on a per-server basis. This limit MUST be reduced if a 199 request times out and MAY be increased if several subsequent queries 200 succeed without a timeout. 202 REQ. 11: If an ALTO query cannot be sent because the maximum number 203 of outstanding queries is reached, the ALTO client MAY wait for some 204 time. Then, if it is still not possible to send the query, it MUST 205 report to the application that no ALTO information is available. In 206 this case, the application has to perform the resource provider 207 selection without ALTO guidance. 209 REQ. 12: An ALTO server, which is operating close to its capacity 210 limit, SHOULD be able to inform clients about its impending overload 211 situation, even if it has not yet to discard excess query messages. 212 An ALTO client receiving a reply message with this overload 213 indication may use the message content for the intended purpose 214 (i.e., guidance with respect to resource provider selection). 215 However, with respect to overload control, it MUST behave as if it 216 had not received a reply. 218 REQ. 13: The ALTO protocol MAY have a mechanism by which the ALTO 219 client can specify the required level of precision. If only a medium 220 amount of data has to be exchanged, it may be sufficient to get a 221 quick answer from the ALTO service, which results in a certain 222 improvement compared to a resource provider selection without any 223 ALTO guidance. If, however, very large amounts of data will be 224 transferred or the association will persist for an extended time, the 225 client might request the ALTO service to spend more resources to make 226 a recommendation that leads to higher improvements. 228 REQ. 14: The ALTO protocol SHOULD support lifetime attributes, to 229 enable caching of recommendations at ALTO clients. The ALTO protocol 230 MAY specify an aging mechanism, which allows to give newer 231 recommendations precedence over older ones. 233 4.3. Security and Privacy 235 REQ. 15: The ALTO protocol MUST be designed in a way that the ALTO 236 service can be provided by an operator which is not the operator of 237 the IP access network. 239 REQ. 16: Different instances of the ALTO service operated by 240 different providers must be able to coexist. 242 REQ. 17: The ALTO protocol MUST support mechanisms for mutual 243 authentication and authorization of ALTO clients and servers. 245 REQ. 18: The ALTO protocol MUST support different levels of detail in 246 queries and responses, in order for the operator of an ALTO service 247 to be able to control how much information (e.g., about the network 248 topology) is disclosed. 250 REQ. 19: The ALTO protocol MUST support different levels of detail in 251 queries and responses, in order to protect the privacy of users, to 252 ensure that the operators of ALTO servers and other users of the same 253 application cannot derive sensitive information. 255 REQ. 20: One ALTO interface SHOULD be defined in a way, that the 256 operator of one ALTO server cannot easily deduce the resource 257 identifier (e.g., file name in P2P file sharing) which the resource 258 consumer seeking ALTO guidance wants to access. 260 REQ. 21: If the ALTO protocol supports including privacy-sensitive 261 information (such as resource identifiers or transport addresses) in 262 the ALTO queries or replies, the protocol MUST also support 263 encryption, in order to protect the privacy of users with respect to 264 third parties. 266 REQ. 22: The ALTO protocol MUST include appropriate mechanisms to 267 protect the ALTO service against DoS attacks. 269 5. Example rating criteria 271 The goal of ALTO is to provide guidance to resource consumers that 272 have to select resource providers. The recommendations may be based 273 on various rating criteria. The following list is not intended to be 274 exhaustive, and it may later be moved to a separate document. 276 o Topological distance between the resource consumer and the 277 candidate resource provider, e.g., the number of traversed 278 autonomous systems (AS), or whether the traffic will be local 279 traffic, peering traffic, or transit traffic. 281 o Expected cost for data exchange between the candidate resource 282 provider and the resource consumer, according to the economic 283 agreements between ISP. They may be expressed as absolute costs 284 or relative costs, compared to retrieving the same data from 285 another candidate resource provider. 287 Rating criteria that SHOULD NOT be used by the ALTO service include: 289 o Performance metrics related to instantaneous congestion status. 290 This has to be probed and adapted to continuously, e.g., using 291 TCP. 293 6. IANA Considerations 295 This requirements document does not mandate any immediate IANA 296 actions. However, such IANA considerations may arise from future 297 ALTO specification documents which try to meet the requirements given 298 here. 300 7. Security Considerations 302 High-level security considerations for the ALTO service can be found 303 in the "Security Considerations" section of the ALTO problem 304 statement [I-D.marocco-alto-problem-statement]. For a set of 305 specific security requirements please refer to Section 4.3 of this 306 document. 308 8. References 310 8.1. Normative References 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 8.2. Informative References 317 [I-D.marocco-alto-problem-statement] 318 Marocco, E. and V. Gurbani, "Application-Layer Traffic 319 Optimization (ALTO) Problem Statement", 320 draft-marocco-alto-problem-statement-03 (work in 321 progress), November 2008. 323 Appendix A. Contributors 325 The authors were supported by the following people, who have 326 contributed to this document: 328 o Jason Livingood 330 o Saverio Niccolini 332 o Jan Seedorf 334 o Martin Stiemerling 336 Appendix B. Acknowledgments 338 The authors would like to thank 340 o Vijay K. Gurbani 342 o Enrico Marocco 344 for fostering discussions that lead to the creation of this document, 345 and for giving valuable comments on it. 347 Sebastian Kiesel, Saverio Niccolini, Jan Seedorf, and Martin 348 Stiemerling are partially supported by the NAPA-WINE project 349 (Network-Aware P2P-TV Application over Wise Networks, 350 http://www.napa-wine.org), a research project supported by the 351 European Commission under its 7th Framework Program (contract no. 352 214412). The views and conclusions contained herein are those of the 353 authors and should not be interpreted as necessarily representing the 354 official policies or endorsements, either expressed or implied, of 355 the NAPA-WINE project or the European Commission. 357 Laird Popkin and Y. Richard Yang are grateful to the many 358 contributions made by the members of the P4P working group and Yale 359 Laboratory of Networked Systems. The P4P working group is hosted by 360 DCIA. 362 Authors' Addresses 364 Sebastian Kiesel (editor) 365 NEC Europe Ltd., Network Laboratories Europe 366 Kurfuersten-Anlage 36 367 Heidelberg 69115 368 Germany 370 Phone: +49 6221 4342 232 371 Email: sebastian.kiesel@nw.neclab.eu 373 Laird Popkin 374 Pando Networks, Inc. 376 Email: laird@pando.com 378 Stefano Previdi 379 Cisco Systems, Inc. 381 Email: sprevidi@cisco.com 383 Richard Woundy 384 Comcast Corporation 386 Email: Richard_Woundy@cable.comcast.com 388 Yang Richard Yang 389 Yale University 391 Email: yry@cs.yale.edu 393 Full Copyright Statement 395 Copyright (C) The IETF Trust (2008). 397 This document is subject to the rights, licenses and restrictions 398 contained in BCP 78, and except as set forth therein, the authors 399 retain all their rights. 401 This document and the information contained herein are provided on an 402 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 403 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 404 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 405 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 406 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 407 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 409 Intellectual Property 411 The IETF takes no position regarding the validity or scope of any 412 Intellectual Property Rights or other rights that might be claimed to 413 pertain to the implementation or use of the technology described in 414 this document or the extent to which any license under such rights 415 might or might not be available; nor does it represent that it has 416 made any independent effort to identify any such rights. Information 417 on the procedures with respect to rights in RFC documents can be 418 found in BCP 78 and BCP 79. 420 Copies of IPR disclosures made to the IETF Secretariat and any 421 assurances of licenses to be made available, or the result of an 422 attempt made to obtain a general license or permission for the use of 423 such proprietary rights by implementers or users of this 424 specification can be obtained from the IETF on-line IPR repository at 425 http://www.ietf.org/ipr. 427 The IETF invites any interested party to bring to its attention any 428 copyrights, patents or patent applications, or other proprietary 429 rights that may cover technology that may be required to implement 430 this standard. Please address the information to the IETF at 431 ietf-ipr@ietf.org.