idnits 2.17.1 draft-ietf-alto-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year == Line 241 has weird spacing: '...logical ser...' == Line 262 has weird spacing: '...logical ser...' -- The document date (April 16, 2009) is 5482 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: October 18, 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 April 16, 2009 14 Application-Layer Traffic Optimization (ALTO) Requirements 15 draft-ietf-alto-reqs-00.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on October 18, 2009. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 Many Internet applications are used to access resources, such as 54 pieces of information or server processes, which are available in 55 several equivalent replicas on different hosts. This includes, but 56 is not limited to, peer-to-peer file sharing applications. The goal 57 of Application-Layer Traffic Optimization (ALTO) is to provide 58 guidance to applications, which have to select one or several hosts 59 from a set of candidates, that are able to provide a desired 60 resource. This guidance shall be based on parameters that affect 61 performance and efficiency of the data transmission between the 62 hosts, e.g., the topological distance. The ultimate goal is to 63 improve performance (or Quality of Experience) in the application 64 while reducing resource consumption in the underlying network 65 infrastructure. 67 This document enumerates requirements for ALTO, which should be 68 considered when specifying, assessing, or comparing protocols and 69 implementations, and it solicits feedback and discussion. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Terminology and architectural framework . . . . . . . . . . . 6 75 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 6 76 2.2. ALTO terminology . . . . . . . . . . . . . . . . . . . . . 6 77 2.3. Architectural framework for ALTO . . . . . . . . . . . . . 6 78 2.4. Sample use cases . . . . . . . . . . . . . . . . . . . . . 7 79 3. ALTO requirements . . . . . . . . . . . . . . . . . . . . . . 9 80 3.1. ALTO client protocol . . . . . . . . . . . . . . . . . . . 9 81 3.1.1. General requirements . . . . . . . . . . . . . . . . . 9 82 3.1.2. Protocol semantics . . . . . . . . . . . . . . . . . . 9 83 3.1.3. Error handling and overload protection . . . . . . . . 11 84 3.2. ALTO server discovery . . . . . . . . . . . . . . . . . . 11 85 3.3. Security and privacy . . . . . . . . . . . . . . . . . . . 12 86 4. Host location attributes . . . . . . . . . . . . . . . . . . . 13 87 5. Rating criteria . . . . . . . . . . . . . . . . . . . . . . . 14 88 5.1. Distance-related rating criteria . . . . . . . . . . . . . 14 89 5.2. Charging-related rating criteria . . . . . . . . . . . . . 15 90 5.3. Performance-related rating criteria . . . . . . . . . . . 15 91 5.4. Inappropriate rating criteria . . . . . . . . . . . . . . 16 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 97 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 20 98 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 101 1. Introduction 103 The motivation for Application-Layer Traffic Optimization (ALTO) is 104 described in the ALTO problem statement: 106 "Peer-to-peer applications, such as file sharing, real-time 107 communication, and live media streaming, use a significant amount of 108 Internet resources. Such applications often transfer large amounts 109 of data in direct peer-to-peer connections. However, they usually 110 have little knowledge of the underlying network topology. As a 111 result, they may choose their peers based on measurements and 112 statistics that, in many situations, may lead to suboptimal choices." 113 [I-D.marocco-alto-problem-statement]. 115 The goal of ALTO is to provide information which can help peer-to- 116 peer (P2P) applications to make better decisions with respect to peer 117 selection. However, ALTO may be useful for non-P2P applications as 118 well. For example, clients of client-server applications may use 119 information provided by ALTO to select one of several servers or 120 information replicas. As another example, ALTO information could be 121 used to select a media relay needed for NAT traversal. The goal of 122 these informed decisions is to improve performance (or Quality of 123 Experience) in the application while reducing resource consumption in 124 the underlying network infrastructure. 126 Usually, it would be difficult or even impossible for application 127 entities to acquire this information by other mechanisms (e.g., using 128 measurements between the peers of a P2P overlay), because of 129 complexity or because it is based on network topology information, 130 network operational costs, or network policies, which the respective 131 network provider does not want to disclose in detail. 133 The logical entities that provide the ALTO service do not take part 134 in the actual user data transport, i.e., they do not implement 135 functions for relaying user data. They may be placed on various 136 kinds of physical nodes, e.g., on dedicated servers, as auxiliary 137 processes in routers, on "trackers" or "super peers" of a P2P 138 application operated by the network provider, etc. 140 2. Terminology and architectural framework 142 2.1. Requirements notation 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 2.2. ALTO terminology 150 This document uses the following ALTO-related terms, which are 151 defined in [I-D.marocco-alto-problem-statement]: 153 Application, Overlay Network, Application protocol, Peer, P2P, 154 Resource, Resource Identifier, Resource Provider, Resource Consumer, 155 Resource Directory, Transport Address, Host Location Attribute, ALTO 156 Service, ALTO Server, ALTO Client, ALTO Client Protocol, ALTO Query, 157 ALTO Reply, ALTO Transaction, Provisioning protocol, Inter ALTO- 158 Server Protocol, Local Traffic, Peering Traffic, Transit Traffic. 160 2.3. Architectural framework for ALTO 162 There are various architectural options how ALTO could be 163 implemented, and specifying or mandating one specific architecture is 164 out of the scope of this document. 166 The ALTO Working Group Charter [ALTO-charter] itemizes several key 167 components, which shall be elaborated and specified by the ALTO 168 Working Group. The ALTO problem statement 169 [I-D.marocco-alto-problem-statement] defines a terminology (see 170 Section 2.2) and presents a figure that gives a high-level overview 171 of protocol interaction between ALTO elements. 173 This document itemizes requirements for the following components of 174 the abovementioned architecture: 176 o The ALTO client protocol, which is used for sending ALTO queries 177 and ALTO replies between ALTO client and ALTO server. 179 o The discovery mechanism, which will be used by ALTO clients in 180 order to find out where to send ALTO requests. 182 o The overall architecture, especially with respect to security and 183 privacy issues. 185 Furthermore, this document describes the following data structures, 186 which might be used in the ALTO client protocol: 188 o Host location attributes, which are used to describe the location 189 of a host in the network topology. 191 o Rating criteria, i. e., properties that shall be evaluated in 192 order to generate the ALTO guidance. 194 Requirements regarding other components are not considered in the 195 current version of this document, but may be added later. 197 2.4. Sample use cases 199 The ALTO problem statement [I-D.marocco-alto-problem-statement] 200 presents a figure that gives a high-level overview of protocol 201 interaction between ALTO elements. The following figures are 202 somewhat more elaborated and extended versions of it, in order to 203 give some non-normative examples of ALTO usage. It can also be seen 204 that, in some use cases, some of the requirements presented in later 205 sections are more relevant than in others. 207 Figure 1 shows an ALTO use case with a DHT-based P2P application. 208 Using this distributed lookup mechanism, a peer can figure out which 209 other peers are candidate resource providers for a desired resource. 210 Every peer software includes an ALTO client, in order to request and 211 receive guidance on peer selection from the ALTO servers. 213 From an ALTO perspective this means that the ALTO servers will 214 receive ALTO queries from a rather large number of different ALTO 215 clients. The performance of many clients and their Internet 216 connectivity may be rather limited and therefore, this puts certain 217 restrictions on the amount of guiding data that can be sent to them. 218 Furthermore, the privacy-sensitive IP addresses of the peers are 219 visible to the (operators of the) ALTO servers, as these are also the 220 source addresses of the ALTO query messages. 222 Figure 2 shows an ALTO use case with a P2P application that makes use 223 of a centralized resource directory (in some specific P2P 224 implementations called a "tracker"). In this scenario the ALTO 225 servers receive queries only from few entities, i.e., the resource 226 directories. As these resource directories must be powerful machines 227 anyway, it may be reasonable to send large amounts of ALTO guidance 228 data to them, which will be cached there. Furthermore, in this 229 scenario it may be possible to hide the exact addresses of the peers 230 from the ALTO server. 232 +-----+ 233 =====| |** 234 ==== +-----+ * 235 ==== * * 236 ==== * * 237 +-----+ +------+===== +-----+ * 238 | |.....| |======================| | * 239 +-----+ +------+===== +-----+ * 240 Source of ALTO ==== * * 241 topological service ==== * * 242 information ==== +-----+ * 243 =====| |** 244 +-----+ 245 Legend: 246 === ALTO client protocol 247 *** Application protocol 248 ... Provisioning protocol 250 Figure 1: Overview of protocol interaction between ALTO elements, 251 scenario without resource directory 253 +-----+ 254 **| |** 255 ** +-----+ * 256 ** * * 257 ** * * 258 +-----+ +------+ +-----+** +-----+ * 259 | |.....| |=====| |**********| | * 260 +-----+ +------+ +-----+** +-----+ * 261 Source of ALTO Resource ** * * 262 topological service directory ** * * 263 information ("tracker") ** +-----+ * 264 **| |** 265 +-----+ 266 Peers 267 Legend: 268 === ALTO client protocol 269 *** Application protocol 270 ... Provisioning protocol 272 Figure 2: Overview of protocol interaction between ALTO elements, 273 scenario with resource directory 275 3. ALTO requirements 277 3.1. ALTO client protocol 279 3.1.1. General requirements 281 REQ. ARv00-1: The ALTO service is provided by one or more ALTO 282 servers. ALTO servers MUST implement the ALTO client protocol, for 283 receiving ALTO queries from ALTO clients and for sending the 284 corresponding ALTO replies. 286 REQ. ARv00-2: ALTO clients MUST implement the ALTO client protocol, 287 for sending ALTO queries to ALTO servers and for receiving the 288 corresponding ALTO replies. 290 REQ. ARv00-3: The detailed specification of a protocol is out of the 291 scope of this document. However, any protocol specification that 292 claims to implement the ALTO client protocol MUST be compliant to the 293 requirements itemized in this document. 295 3.1.2. Protocol semantics 297 REQ. ARv00-4: The format of the ALTO query message MUST allow the 298 ALTO client to solicit guidance for selecting appropriate resource 299 providers. 301 REQ. ARv00-5: The ALTO guidance is be based on the evaluation of one 302 or several rating criteria (see Section 5). The ALTO query message 303 SHOULD allow the ALTO client to express which rating criteria should 304 be considered, as well as their relative relevance for the specific 305 application that will eventually make use of the guidance. 307 REQ. ARv00-6: The format of the ALTO reply message MUST allow the 308 ALTO server to express his guidance for selecting appropriate 309 resource providers. 311 With respect to the placement of ALTO clients, several modes of 312 operation exist: 314 o One mode of ALTO operation is that ALTO clients may be embedded 315 directly in the resource consumer (e.g., peer of a DHT-based P2P 316 application), which wants to access a resource. 318 o Another mode of operation is to perform ALTO queries indirectly, 319 via resource directories (e.g., tracker of a P2P application), 320 which may issue ALTO queries to solicit preference on potential 321 resource providers, considering the respective resource consumer. 323 REQ. ARv00-7: The ALTO client protocol MUST support the mode of 324 operation, in which the ALTO client is directly embedded in the 325 resource consumer. 327 REQ. ARv00-8: The ALTO client protocol MUST support the mode of 328 operation, in which the ALTO client is embedded in the resource 329 directory. 331 With respect to the timing of ALTO queries, several modes of 332 operation exist: 334 o In target-aware query mode, an ALTO client performs the ALTO query 335 when the desired resource and a set of candidate resource 336 providers are already known, i. e., after DHT lookups, queries to 337 the resource directory, etc. 339 o In target-independent query mode, ALTO queries are performed in 340 advance or periodically, in order to receive "target-independent" 341 guidance, which will be cached locally and evaluated later, when a 342 resource is to be accessed. 344 REQ. ARv00-9: The ALTO client protocol MUST support at least one of 345 these two modes, either the target-aware or the target-independent 346 query mode. 348 REQ. ARv00-10: The ALTO client protocol SHOULD support both the 349 target-aware and the target-independent query mode. 351 REQ. ARv00-11: The ALTO client protocol SHOULD support lifetime 352 attributes, to enable caching of recommendations at ALTO clients. 354 REQ. ARv00-12: The ALTO client protocol SHOULD specify an aging 355 mechanism, which allows to give newer recommendations precedence over 356 older ones. 358 REQ. ARv00-13: The ALTO client protocol MUST be designed in a way 359 that the ALTO service can be provided by an operator which is not the 360 operator of the IP access network. 362 REQ. ARv00-14: The ALTO client protocol MUST be designed in a way 363 that different instances of the ALTO service operated by different 364 providers can coexist. 366 REQ. ARv00-15: The ALTO client protocol MUST include support for 367 adding protocol extensions in a non-disruptive, backward-compatible 368 way. 370 REQ. ARv00-16: The ALTO client protocol MUST include protocol 371 versioning support, in order to clearly distinguish between 372 incompatible major versions of the protocol. 374 3.1.3. Error handling and overload protection 376 REQ. ARv00-17: Any application designed to use ALTO MUST also work 377 if no ALTO servers can be found or if no responses to ALTO queries 378 are received, e.g., due to connectivity problems or overload 379 situation. 381 REQ. ARv00-18: The ALTO client protocol MUST use TCP based 382 transport. 384 REQ. ARv00-19: An ALTO server, which is operating close to its 385 capacity limit, MUST be able to inform clients about its impending 386 overload situation, and require them to throttle their query rate. 388 REQ. ARv00-20: An ALTO server, which is operating close to its 389 capacity limit, MUST be able to inform clients about its impending 390 overload situation, and redirect them to another ALTO server. 392 REQ. ARv00-21: An ALTO server, which is operating close to its 393 capacity limit, MUST be able to inform clients about its impending 394 overload situation, and terminate the conversation with the ALTO 395 client. 397 REQ. ARv00-22: An ALTO server, which is operating close to its 398 capacity limit, MUST be able to inform clients about its impending 399 overload situation, and reject new conversation attempts. 401 3.2. ALTO server discovery 403 REQ. ARv00-23: ALTO clients MUST be able to use the ALTO server 404 discovery mechanism, in order to find out where to send ALTO queries. 406 REQ. ARv00-24: The ALTO server discovery mechanism SHOULD be able to 407 return the respective contact information for several ALTO servers. 409 REQ. ARv00-25: The ALTO server discovery mechanism SHOULD be able to 410 indicate preferences for each returned ALTO server contact 411 information. 413 REQ. ARv00-26: The ALTO server discovery mechanism SHOULD be 414 independent of specific link-layer protocols or access network 415 architectures. For example, many broadband access networks use DHCP 416 for configuration, while others use PPPoE. In contrast, DNS is 417 available in virtually all Internet access networks. 419 3.3. Security and privacy 421 REQ. ARv00-27: The ALTO client protocol MUST support mechanisms for 422 mutual authentication and authorization of ALTO clients and servers. 424 REQ. ARv00-28: The ALTO client protocol MUST support different 425 levels of detail in queries and responses, in order for the operator 426 of an ALTO service to be able to control how much information (e.g., 427 about the network topology) is disclosed. 429 REQ. ARv00-29: The ALTO client protocol MUST support different 430 levels of detail in queries and responses, in order to protect the 431 privacy of users, to ensure that the operators of ALTO servers and 432 other users of the same application cannot derive sensitive 433 information. 435 REQ. ARv00-30: The ALTO client protocol SHOULD be defined in a way, 436 that the operator of one ALTO server cannot easily deduce the 437 resource identifier (e.g., file name in P2P file sharing) which the 438 resource consumer seeking ALTO guidance wants to access. 440 REQ. ARv00-31: The ALTO protocol MUST include appropriate mechanisms 441 to protect the ALTO service against DoS attacks. 443 4. Host location attributes 445 Host location attributes are used in the ALTO client protocol to 446 describe the location of a host in the network topology. The 447 following list gives an overview on such attributes that have been 448 proposed in the past, or which are in use by by ALTO-related 449 prototype implementations. 451 One possible way forward is to define the syntax and semantics of a 452 mandatory set of attributes, which have to be understood by all 453 entities that implement the ALTO client protocol. Furthermore, 454 defining a set of optional attributes, as well as a procedure for 455 allocating new attributes (e.g., an IANA registry) may be required. 456 However, there was no broad discussion of this issue so far and no 457 consensus has been reached. Therefore, the only purpose of the 458 following list is to document the attributes that have been proposed 459 so far, and to solicit further feedback and discussion: 461 o IP address or range of IP addresses (in CIDR notation) 463 o Autonomous System (AS) number 465 o Protocol-specific group identifiers, which expand to a set of IP 466 address ranges (CIDR) and/or AS numbers. In one specific solution 467 proposal, these are called Partition ID (PID). 469 5. Rating criteria 471 Rating criteria are used in the ALTO client protocol to express 472 topology- or connectivity-related properties, which are evaluated in 473 order to generate the ALTO guidance. The following list gives an 474 overview on such rating criteria that have been proposed in the past, 475 or which are in use by by ALTO-related prototype implementations. 477 One possible way forward is to define the syntax and semantics of a 478 mandatory set of criteria, which have to be understood by all 479 entities that implement the ALTO client protocol. Furthermore, 480 defining a set of optional criteria, as well as a procedure for 481 allocating new criteria (e.g., an IANA registry) may be required. 482 However, there was no broad discussion of this issue so far and no 483 consensus has been reached. Therefore, the only purpose of the 484 following list is to document the attributes that have been proposed 485 so far, and to solicit further feedback and discussion. 487 5.1. Distance-related rating criteria 489 o Relative topological distance: relative means that a larger 490 numerical value means greater distance, but it is up to the ALTO 491 service how to compute the values, and the ALTO client will not be 492 informed about the nature of the information. One way of 493 generating this kind of information MAY be counting AS hops, but 494 when querying this parameter, the ALTO client MUST NOT assume that 495 the numbers actually are AS hops. 497 o Absolute topological distance, expressed in the number of 498 traversed autonomous systems (AS). 500 o Absolute topological distance, expressed in the number of router 501 hops (i.e., how much the TTL value of an IP packet will be 502 decreased during transit). 504 o Absolute physical distance, based on knowledge of the approximate 505 geolocation (continent, country) of an IP address. 507 o Relative operator's preference: higher numerical value indicates 508 that the application should prefer this candidate resource 509 provider over others with lower values (if no other reasons speak 510 against it, such as probed throughput). Again, as this is a 511 relative measure, the ALTO service does not have to indicate how 512 the values have been computed. Examples could be: cost for 513 peering or transit traffic, traffic engineering inside the own 514 network, and other policies. 516 5.2. Charging-related rating criteria 518 o Traffic volume caps, in case the Internet access of the resource 519 consumer is not charged by "flat rate". For each candidate 520 resource provider, the ALTO service could indicate the amount of 521 data that may be transferred from/to this resource provider until 522 a given point in time, and how much of this amount has already 523 been consumed. Furthermore, it would have to be indicated how 524 excess traffic would be handled (e.g., blocked, throttled, or 525 charged separately at an indicated price). The interaction of 526 several applications running on a host, out of which some use this 527 attribute while others don't, as well as the evaluation of this 528 attribute in resource directories, which issue ALTO queries on 529 behalf of other peers, are for further study. 531 5.3. Performance-related rating criteria 533 The following rating criteria are subject to the remarks below. 535 o The minimum achievable throughput between the resource consumer 536 and the candidate resource provider, which is considered useful by 537 the application (only in ALTO queries), or 539 o An arbitrary upper bound for the throughput from/to the candidate 540 resource provider (only in ALTO replies). This may be, but is not 541 necessarily the provisioned access bandwidth of the candidate 542 resource provider. 544 o The maximum round-trip time (RTT) between resource consumer and 545 the candidate resource provider, which is acceptable for the 546 application for useful communication with the candidate resource 547 provider (only in ALTO queries), or 549 o An arbitrary lower bound for the RTT between resource consumer and 550 the candidate resource provider (only in ALTO replies). This may 551 be, for example, based on measurements of the propagation delay in 552 a completely unloaded network. 554 The ALTO client MUST be aware, that with high probability, the actual 555 performance values differ significantly from these upper and lower 556 bounds. In particular, an ALTO client MUST NOT consider the "upper 557 bound for throughput" parameter as a permission to send data at the 558 indicated rate without using congestion control mechanisms. 560 The discrepancies are due to various reasons, including, but not 561 limited to the facts that 562 o the ALTO service is not an admission control system 564 o the ALTO service may not know the instantaneous congestion status 565 of the network 567 o the ALTO service may not know all link bandwidths, i.e., where the 568 bottleneck really is, and there may be shared bottlenecks 570 o the ALTO service may not know whether the candidate peer itself is 571 overloaded 573 o the ALTO service may not know whether the candidate peer throttles 574 the bandwidth it devotes for the considered application 576 o the ALTO service may not know whether the candidate peer will 577 throttle the data it sends to us (e.g., because of some fairness 578 algorithm, such as tit-for-tat) 580 Because of these inaccuracies and the lack of complete, instantaneous 581 state information, which are inherent to the ALTO service, the 582 application must use other mechanisms (such as passive measurements 583 on actual data transmissions) to assess the currently achievable 584 throughput, and it MUST use appropriate congestion control mechanisms 585 in order to avoid a congestion collapse. Nevertheless, these rating 586 criteria may provide a useful shortcut for quickly excluding 587 candidate resource providers from such probing, if it is known in 588 advance that connectivity is in any case worse than what is 589 considered the minimum useful value by the respective application. 591 5.4. Inappropriate rating criteria 593 Rating criteria that SHOULD NOT be defined for and used by the ALTO 594 service include: 596 o Performance metrics that are closely related to the instantaneous 597 congestion status. The definition of alternate approaches for 598 congestion control is explicitly out of the scope of ALTO. 599 Instead, other appropriate means, such as using TCP based 600 transport, have to be used to avoid congestion. 602 6. IANA Considerations 604 This requirements document does not mandate any immediate IANA 605 actions. However, such IANA considerations may arise from future 606 ALTO specification documents which try to meet the requirements given 607 here. 609 7. Security Considerations 611 High-level security considerations for the ALTO service can be found 612 in the "Security Considerations" section of the ALTO problem 613 statement [I-D.marocco-alto-problem-statement]. For a set of 614 specific security requirements please refer to Section 3.3 of this 615 document. 617 8. References 619 8.1. Normative References 621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", BCP 14, RFC 2119, March 1997. 624 8.2. Informative References 626 [ALTO-charter] 627 Marocco, E. and V. Gurbani, "Application-Layer Traffic 628 Optimization (ALTO) Working Group Charter", February 2009. 630 [I-D.marocco-alto-problem-statement] 631 Seedorf, J. and E. Burger, "Application-Layer Traffic 632 Optimization (ALTO) Problem Statement", 633 draft-marocco-alto-problem-statement-05 (work in 634 progress), March 2009. 636 Appendix A. Contributors 638 The authors were supported by the following people, who have 639 contributed to this document: 641 o Zoran Despotovic 643 o Jason Livingood 645 o Saverio Niccolini 647 o Jan Seedorf 649 o Martin Stiemerling 651 The authors would like to thank the members of the P2PI and ALTO 652 mailing lists for their feedback. 654 Appendix B. Acknowledgments 656 The authors would like to thank 658 o Vijay K. Gurbani 660 o Enrico Marocco 662 for fostering discussions that lead to the creation of this document, 663 and for giving valuable comments on it. 665 Sebastian Kiesel, Saverio Niccolini, Jan Seedorf, and Martin 666 Stiemerling are partially supported by the NAPA-WINE project 667 (Network-Aware P2P-TV Application over Wise Networks, 668 http://www.napa-wine.org), a research project supported by the 669 European Commission under its 7th Framework Program (contract no. 670 214412). The views and conclusions contained herein are those of the 671 authors and should not be interpreted as necessarily representing the 672 official policies or endorsements, either expressed or implied, of 673 the NAPA-WINE project or the European Commission. 675 Laird Popkin and Y. Richard Yang are grateful to the many 676 contributions made by the members of the P4P working group and Yale 677 Laboratory of Networked Systems. The P4P working group is hosted by 678 DCIA. 680 Authors' Addresses 682 Sebastian Kiesel (editor) 683 NEC Europe Ltd., Network Laboratories Europe 684 Kurfuersten-Anlage 36 685 Heidelberg 69115 686 Germany 688 Phone: +49 6221 4342 232 689 Email: sebastian.kiesel@nw.neclab.eu 691 Laird Popkin 692 Pando Networks, Inc. 694 Email: laird@pando.com 696 Stefano Previdi 697 Cisco Systems, Inc. 699 Email: sprevidi@cisco.com 701 Richard Woundy 702 Comcast Corporation 704 Email: Richard_Woundy@cable.comcast.com 706 Yang Richard Yang 707 Yale University 709 Email: yry@cs.yale.edu