idnits 2.17.1 draft-ietf-alto-reqs-02.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 265 has weird spacing: '...logical ser...' == Line 285 has weird spacing: '...logical ser...' -- The document date (October 23, 2009) is 5292 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-kiesel-alto-3pdisc-00 Summary: 1 error (**), 0 flaws (~~), 4 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: April 26, 2010 Pando Networks, Inc. 6 S. Previdi 7 Cisco Systems, Inc. 8 R. Woundy 9 Comcast Corporation 10 Y R. Yang 11 Yale University 12 October 23, 2009 14 Application-Layer Traffic Optimization (ALTO) Requirements 15 draft-ietf-alto-reqs-02.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 April 26, 2010. 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 . . . . . . . . . . . . . 7 78 2.4. Sample use cases . . . . . . . . . . . . . . . . . . . . . 7 79 3. ALTO requirements . . . . . . . . . . . . . . . . . . . . . . 10 80 3.1. ALTO client protocol . . . . . . . . . . . . . . . . . . . 10 81 3.1.1. General requirements . . . . . . . . . . . . . . . . . 10 82 3.1.2. Host group descriptor support . . . . . . . . . . . . 10 83 3.1.3. Rating criteria support . . . . . . . . . . . . . . . 11 84 3.1.4. Placement of entities and timing of transactions . . . 12 85 3.1.5. Protocol extensibility . . . . . . . . . . . . . . . . 13 86 3.1.6. Error handling and overload protection . . . . . . . . 14 87 3.2. ALTO server discovery . . . . . . . . . . . . . . . . . . 14 88 3.3. Security and privacy . . . . . . . . . . . . . . . . . . . 15 89 4. Host group descriptors . . . . . . . . . . . . . . . . . . . . 17 90 5. Rating criteria . . . . . . . . . . . . . . . . . . . . . . . 18 91 5.1. Distance-related rating criteria . . . . . . . . . . . . . 18 92 5.2. Charging-related rating criteria . . . . . . . . . . . . . 18 93 5.3. Performance-related rating criteria . . . . . . . . . . . 19 94 5.4. Inappropriate rating criteria . . . . . . . . . . . . . . 20 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 99 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 100 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 24 101 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 104 1. Introduction 106 The motivation for Application-Layer Traffic Optimization (ALTO) is 107 described in the ALTO problem statement 108 [I-D.ietf-alto-problem-statement]. 110 The goal of ALTO is to provide information which can help peer-to- 111 peer (P2P) applications to make better decisions with respect to peer 112 selection. However, ALTO may be useful for non-P2P applications as 113 well. For example, clients of client-server applications may use 114 information provided by ALTO to select one of several servers or 115 information replicas. As another example, ALTO information could be 116 used to select a media relay needed for NAT traversal. The goal of 117 these informed decisions is to improve performance (or Quality of 118 Experience) in the application while reducing resource consumption in 119 the underlying network infrastructure. 121 Usually, it would be difficult or even impossible for application 122 entities to acquire this information by other mechanisms (e.g., using 123 measurements between the peers of a P2P overlay), because of 124 complexity or because it is based on network topology information, 125 network operational costs, or network policies, which the respective 126 network provider does not want to disclose in detail. 128 The logical entities that provide the ALTO service do not take part 129 in the actual user data transport, i.e., they do not implement 130 functions for relaying user data. They may be placed on various 131 kinds of physical nodes, e.g., on dedicated servers, as auxiliary 132 processes in routers, on "trackers" or "super peers" of a P2P 133 application operated by the network provider, etc. 135 2. Terminology and architectural framework 137 2.1. Requirements notation 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2.2. ALTO terminology 145 This document uses the following ALTO-related terms, which are 146 defined in [I-D.ietf-alto-problem-statement]: 148 Application, Overlay Network, Application protocol, Peer, P2P, 149 Resource, Resource Identifier, Resource Provider, Resource Consumer, 150 Resource Directory, Transport Address, ALTO Service, ALTO Server, 151 ALTO Client, ALTO Client Protocol, ALTO Query, ALTO Reply, ALTO 152 Transaction, Provisioning protocol, Inter ALTO-Server Protocol, Local 153 Traffic, Peering Traffic, Transit Traffic. 155 Furthermore, the following additonal terms will be used: 157 o Host Group Descriptor: Information used to describe the resouce 158 consumer which seeks ALTO guidance, or one or several candidate 159 resource providers. This can be, for example, a single IP 160 address, an address prefix or address range that contains the 161 host(s), or an autonomous system (AS) number. Different options 162 may provide different levels of detail. Depending on the system 163 architecture, this may have implications on the quality of the 164 guidance ALTO is able to provide, on whether recommendations can 165 be aggregated, and on how much privacy-sensitive information about 166 users might be disclosed to additional parties. 168 o Host Characteristics Attribute: Properties of a host (other than 169 the host group descriptor), in particular related to its 170 attachment to the network. This information may be stored in the 171 ALTO server and transmitted in the ALTO protocol. It may be 172 evaluated according to the rating criteria. 174 o Rating Criterion: The condition or relation that defines the 175 "better" in "better-than-random peer selection", which is the 176 ultimate goal of ALTO. Examples may include "host's Internet 177 access is not subject to volume based charging (flat rate)" or 178 "low topological distance". Some rating criteria, such as "low 179 topological distance", need to include a reference point, i. e., 180 "low topological distance from a given resource consumer", which 181 can be described by means of a host group descriptor. 183 2.3. Architectural framework for ALTO 185 There are various architectural options how ALTO could be 186 implemented, and specifying or mandating one specific architecture is 187 out of the scope of this document. 189 The ALTO Working Group Charter [ALTO-charter] itemizes several key 190 components, which shall be elaborated and specified by the ALTO 191 Working Group. The ALTO problem statement 192 [I-D.ietf-alto-problem-statement] defines a terminology (see 193 Section 2.2) and presents a figure that gives a high-level overview 194 of protocol interaction between ALTO elements. 196 This document itemizes requirements for the following components of 197 the abovementioned architecture: 199 o The ALTO client protocol, which is used for sending ALTO queries 200 and ALTO replies between ALTO client and ALTO server. 202 o The discovery mechanism, which will be used by ALTO clients in 203 order to find out where to send ALTO requests. 205 o The overall architecture, especially with respect to security and 206 privacy issues. 208 Furthermore, this document describes the following data structures, 209 which might be used in the ALTO client protocol: 211 o Host group descriptors, which are used to describe the location of 212 a host in the network topology. 214 o Rating criteria, i. e., conditions that shall be evaluated in 215 order to generate the ALTO guidance. 217 Requirements regarding other components are not considered in the 218 current version of this document, but may be added later. 220 2.4. Sample use cases 222 The ALTO problem statement [I-D.ietf-alto-problem-statement] presents 223 a figure that gives a high-level overview of protocol interaction 224 between ALTO elements. The following figures are somewhat more 225 elaborated and extended versions of it, in order to give some non- 226 normative examples of ALTO usage. It can also be seen that, in some 227 use cases, some of the requirements presented in later sections are 228 more relevant than in others. 230 Figure 1 shows an ALTO use case with a DHT-based P2P application. 232 Using this distributed lookup mechanism, a peer can figure out which 233 other peers are candidate resource providers for a desired resource. 234 Every peer software includes an ALTO client, in order to request and 235 receive guidance on peer selection from the ALTO servers. 237 From an ALTO perspective this means that the ALTO servers will 238 receive ALTO queries from a rather large number of different ALTO 239 clients. The performance of many clients and their Internet 240 connectivity may be rather limited and therefore, this puts certain 241 restrictions on the amount of guiding data that can be sent to them. 242 Furthermore, the privacy-sensitive IP addresses of the peers are 243 visible to the (operators of the) ALTO servers, as these are also the 244 source addresses of the ALTO query messages. 246 Figure 2 shows an ALTO use case with a P2P application that makes use 247 of a centralized resource directory (in some specific P2P 248 implementations called a "tracker"). In this scenario the ALTO 249 servers receive queries only from few entities, i.e., the resource 250 directories. As these resource directories must be powerful machines 251 anyway, it may be reasonable to send large amounts of ALTO guidance 252 data to them, which will be cached there. Furthermore, in this 253 scenario it may be possible to hide the exact addresses of the peers 254 from the ALTO server. 256 +-----+ 257 =====| |** 258 ==== +-----+ * 259 ==== * * 260 ==== * * 261 +-----+ +------+===== +-----+ * 262 | |.....| |======================| | * 263 +-----+ +------+===== +-----+ * 264 Source of ALTO ==== * * 265 topological service ==== * * 266 information ==== +-----+ * 267 =====| |** 268 +-----+ 269 Legend: 270 === ALTO client protocol 271 *** Application protocol 272 ... Provisioning protocol 274 Figure 1: Overview of protocol interaction between ALTO elements, 275 scenario without resource directory 276 +-----+ 277 **| |** 278 ** +-----+ * 279 ** * * 280 ** * * 281 +-----+ +------+ +-----+** +-----+ * 282 | |.....| |=====| |**********| | * 283 +-----+ +------+ +-----+** +-----+ * 284 Source of ALTO Resource ** * * 285 topological service directory ** * * 286 information ("tracker") ** +-----+ * 287 **| |** 288 +-----+ 289 Peers 290 Legend: 291 === ALTO client protocol 292 *** Application protocol 293 ... Provisioning protocol 295 Figure 2: Overview of protocol interaction between ALTO elements, 296 scenario with resource directory 298 3. ALTO requirements 300 3.1. ALTO client protocol 302 3.1.1. General requirements 304 REQ. ARv02-1: The ALTO service is provided by one or more ALTO 305 servers. ALTO servers MUST implement the ALTO client protocol, for 306 receiving ALTO queries from ALTO clients and for sending the 307 corresponding ALTO replies. 309 REQ. ARv02-2: ALTO clients MUST implement the ALTO client protocol, 310 for sending ALTO queries to ALTO servers and for receiving the 311 corresponding ALTO replies. 313 REQ. ARv02-3: The format of the ALTO query message MUST allow the 314 ALTO client to solicit guidance for selecting appropriate resource 315 providers. 317 REQ. ARv02-4: The format of the ALTO reply message MUST allow the 318 ALTO server to express its guidance for selecting appropriate 319 resource providers. 321 REQ. ARv02-5: The detailed specification of a protocol is out of the 322 scope of this document. However, any protocol specification that 323 claims to implement the ALTO client protocol MUST be compliant to the 324 requirements itemized in this document. 326 3.1.2. Host group descriptor support 328 The ALTO guidance is based on the evaluation of several resource 329 providers or groups of resource providers, which are characterized by 330 means of host group descriptors, considering one or several rating 331 criteria. 333 REQ. ARv02-6: The ALTO client protocol MUST support the usage of 334 several different host group descriptor types. 336 REQ. ARv02-7: The ALTO client protocol specification MUST define a 337 basic set of host group descriptor types, which MUST be supported by 338 all implementations of the ALTO client protocol. 340 REQ. ARv02-8: The ALTO client protocol MUST support the host group 341 descriptor types "IPv4 address prefix" and "IPv6 address prefix." 342 They can be used to specify the IP address of one host, or an IP 343 address range (in CIDR notation), which contains all hosts in 344 question. It is also possible to specify a broader address range 345 (i.e., a shorter prefix length) than the intended group of hosts 346 actually uses, in order to conceal their exact identity. 348 REQ. ARv02-9: The ALTO client protocol specification MUST define an 349 appropriate procedure for adding new host group descriptor types, 350 e.g., by establishing an IANA registry. 352 See Section 4 for a discussion of possible other host group 353 descriptor types. 355 REQ. ARv02-10: ALTO clients and ALTO servers MUST clearly identify 356 the type of each host group descriptor sent in ALTO queries or 357 replies. 359 REQ. ARv02-11: For host group descriptor types other than "IPv4 360 address prefix" and "IPv6 address prefix", the host group descriptor 361 type identification MUST be supplemented by a reference to a 362 facility, which can be used to translate host group descriptors of 363 that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping 364 table or an algorithm. 366 REQ. ARv02-12: Protocol functions for mapping other host group 367 descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and 368 specified as part of the ALTO client protocol, and the corresponding 369 address mapping information SHOULD be made available by the same 370 entity that wants to use these host group descriptors within the ALTO 371 client protocol. However, an ALTO server or an ALTO client MAY also 372 send a reference to an external mapping facility, e.g., a translation 373 table to be downloaded as file via HTTP. 375 REQ. ARv02-13: The ALTO client protocol specification MUST define 376 mechanisms, which can be used by the ALTO client and the ALTO server 377 to indicate that a host group descriptor used by the other party is 378 of an unsupported type, or that the indicated mapping mechanism could 379 not be used. 381 3.1.3. Rating criteria support 383 REQ. ARv02-14: The ALTO client protocol MUST support the usage of 384 several different rating criteria types. 386 REQ. ARv02-15: The ALTO client protocol specification MUST define a 387 basic set of rating criteria types, which MUST be supported by all 388 implementations of the ALTO client protocol. 390 REQ. ARv02-16: The ALTO client protocol specification MUST support 391 the rating criteria type "relative operator's preference." This is a 392 relative measure, i.e., it is not associtated with any unit of 393 measurement. A higher rating according to this criterion indicates 394 that the application should prefer the respective candidate resource 395 provider over others with lower ratings (if no other reasons speak 396 against it, such as transmission attempts suggesting that the path is 397 currently congested). The operator of the ALTO server does not have 398 to disclose how and based on which data the ratings are actually 399 computed. Examples could be: cost for peering or transit traffic, 400 traffic engineering inside the network, and other policies. 402 REQ. ARv02-17: The ALTO client protocol specification MUST define an 403 appropriate procedure for adding new rating criteria types, e.g., by 404 establishing an IANA registry. 406 See Section 5 for a discussion of possible other rating criteria. 408 REQ. ARv02-18:The ALTO query message SHOULD allow the ALTO client to 409 express which rating criteria should be considered, as well as their 410 relative relevance for the specific application that will eventually 411 make use of the guidance. 413 REQ. ARv02-19:The ALTO reply message SHOULD allow the ALTO server to 414 express which rating criteria have been considered when generating 415 the reply. 417 REQ. ARv02-20: The ALTO client protocol specification MUST define 418 mechanisms, which can be used by the ALTO client and the ALTO server 419 to indicate that a rating criteria used by the other party is of an 420 unsupported type. 422 3.1.4. Placement of entities and timing of transactions 424 With respect to the placement of ALTO clients, several modes of 425 operation exist: 427 o One mode of ALTO operation is that ALTO clients may be embedded 428 directly in the resource consumer (e.g., peer of a DHT-based P2P 429 application), which wants to access a resource. 431 o Another mode of operation is to perform ALTO queries indirectly, 432 via resource directories (e.g., tracker of a P2P application), 433 which may issue ALTO queries to solicit preference on potential 434 resource providers, considering the respective resource consumer. 436 REQ. ARv02-21: The ALTO client protocol MUST support the mode of 437 operation, in which the ALTO client is directly embedded in the 438 resource consumer. 440 REQ. ARv02-22: The ALTO client protocol MUST support the mode of 441 operation, in which the ALTO client is embedded in the resource 442 directory. 444 REQ. ARv02-23: The ALTO client protocol MUST be designed in a way 445 that the ALTO service can be provided by an operator which is not the 446 operator of the IP access network. 448 REQ. ARv02-24: The ALTO client protocol MUST be designed in a way 449 that different instances of the ALTO service operated by different 450 providers can coexist. 452 With respect to the timing of ALTO queries, several modes of 453 operation exist: 455 o In target-aware query mode, an ALTO client performs the ALTO query 456 when the desired resource and a set of candidate resource 457 providers are already known, i. e., after DHT lookups, queries to 458 the resource directory, etc. 460 o In target-independent query mode, ALTO queries are performed in 461 advance or periodically, in order to receive comprehensive, 462 "target-independent" guidance, which will be cached locally and 463 evaluated later, when a resource is to be accessed. 465 REQ. ARv02-25: The ALTO client protocol MUST support at least one of 466 these two modes, either the target-aware or the target-independent 467 query mode. 469 REQ. ARv02-26: The ALTO client protocol SHOULD support both the 470 target-aware and the target-independent query mode. 472 REQ. ARv02-27: The ALTO client protocol SHOULD support lifetime 473 attributes, to enable caching of recommendations at ALTO clients. 475 REQ. ARv02-28: The ALTO client protocol SHOULD specify an aging 476 mechanism, which allows to give newer recommendations precedence over 477 older ones. 479 REQ. ARv02-29: The ALTO client protocol MUST support scenarios with 480 the ALTO client located in the private address realm behind a network 481 address translator (NAT). There are different types of NAT, see 482 [RFC4787] and [RFC5382]. 484 3.1.5. Protocol extensibility 486 REQ. ARv02-30: The ALTO client protocol MUST include support for 487 adding protocol extensions in a non-disruptive, backward-compatible 488 way. 490 REQ. ARv02-31: The ALTO client protocol MUST include protocol 491 versioning support, in order to clearly distinguish between 492 incompatible major versions of the protocol. 494 3.1.6. Error handling and overload protection 496 REQ. ARv02-32: Any application designed to use ALTO MUST also work 497 if no ALTO servers can be found or if no responses to ALTO queries 498 are received, e.g., due to connectivity problems or overload 499 situation. 501 REQ. ARv02-33: The ALTO client protocol MUST use TCP based 502 transport. 504 REQ. ARv02-34: An ALTO server, which is operating close to its 505 capacity limit, MUST be able to inform clients about its impending 506 overload situation, and require them to throttle their query rate. 508 REQ. ARv02-35: An ALTO server, which is operating close to its 509 capacity limit, MUST be able to inform clients about its impending 510 overload situation, and redirect them to another ALTO server. 512 REQ. ARv02-36: An ALTO server, which is operating close to its 513 capacity limit, MUST be able to inform clients about its impending 514 overload situation, and terminate the conversation with the ALTO 515 client. 517 REQ. ARv02-37: An ALTO server, which is operating close to its 518 capacity limit, MUST be able to inform clients about its impending 519 overload situation, and reject new conversation attempts. 521 3.2. ALTO server discovery 523 The ALTO client protocol is supported by one or several ALTO server 524 discovery mechanisms, which will be used by ALTO clients in order to 525 find out where to send ALTO requests. 527 REQ. ARv02-38: ALTO clients which are embedded in the resource 528 consumer MUST be able to use the ALTO server discovery mechanism, in 529 order to find one or several ALTO servers that can provide ALTO 530 guidance suitable for the resource consumer. This mode of operation 531 is called "resource consumer initiated ALTO server discovery". 533 REQ. ARv02-39: ALTO clients which are embedded in a resource 534 directory and perform third-party ALTO queries on behalf of a remote 535 resource consumer MUST be able to use the ALTO server discovery 536 mechanism, in order to find one or several ALTO servers that can 537 provide ALTO guidance suitable for the respective resource consumer. 539 This mode of operation is called "third-party ALTO server discovery". 540 A classification and evaluation of architectural options for third- 541 party ALTO server discovery can be found in [I-D.kiesel-alto-3pdisc]. 543 REQ. ARv02-40: ALTO clients MUST be able to perform resource 544 consumer initiated ALTO server discovery, even if they are located 545 behind a network address translator (NAT). 547 REQ. ARv02-41: ALTO clients MUST be able to perform third-party ALTO 548 server discovery, even if they are located behind a network address 549 translator (NAT). 551 REQ. ARv02-42: ALTO clients MUST be able to perform third-party ALTO 552 server discovery, even if the resource consumer, on behalf of which 553 the ALTO query will be sent, is located behind a network address 554 translator (NAT). 556 REQ. ARv02-43: The ALTO server discovery mechanism may be specified 557 and provided using an existing protocol or mechanism, such as DNS, 558 DHCP, or PPP based automatic configuration, etc. These candidate 559 "base protocols" differ with respect to their availability in various 560 access network archtitectures and their suitability for third-party 561 queries. When evaluating different options this should be taken into 562 account, in order to limit the total number of ALTO server discovery 563 mechanisms that have to be specified for supporting a reasonably wide 564 range of deployment scenarios. 566 REQ. ARv02-44: The ALTO server discovery mechanism SHOULD be able to 567 return the respective contact information for several ALTO servers. 569 REQ. ARv02-45: The ALTO server discovery mechanism SHOULD be able to 570 indicate preferences for each returned ALTO server contact 571 information. 573 3.3. Security and privacy 575 REQ. ARv02-46: The ALTO client protocol MUST support mechanisms for 576 the authentication of ALTO servers. 578 REQ. ARv02-47: The ALTO client protocol MUST support mechanisms for 579 the authentication of ALTO clients. 581 REQ. ARv02-48: The ALTO client protocol MUST support different 582 levels of detail in queries and responses, in order for the operator 583 of an ALTO service to be able to control how much information (e.g., 584 about the network topology) is disclosed. 586 REQ. ARv02-49: The ALTO client protocol MUST support different 587 levels of detail in queries and responses, in order to protect the 588 privacy of users, to ensure that the operators of ALTO servers and 589 other users of the same application cannot derive sensitive 590 information. 592 REQ. ARv02-50: The ALTO client protocol SHOULD be defined in a way, 593 that the operator of one ALTO server cannot easily deduce the 594 resource identifier (e.g., file name in P2P file sharing) which the 595 resource consumer seeking ALTO guidance wants to access. 597 REQ. ARv02-51: The ALTO client protocol MUST include appropriate 598 mechanisms to protect the ALTO service against DoS attacks. 600 4. Host group descriptors 602 Host group descriptors are used in the ALTO client protocol to 603 describe the location of a host in the network topology. The ALTO 604 client protocol specification defines a basic set of host group 605 descriptor types, which have to be suported by all implementations, 606 and an extension procedure for adding new descriptor types (see 607 Section 3.1.2). The following list gives an overview on further host 608 group descriptor types that have been proposed in the past, or which 609 are in use by by ALTO-related prototype implementations. This list 610 is not intended as normative text. Instead, the only purpose of the 611 following list is to document the descriptor types that have been 612 proposed so far, and to solicit further feedback and discussion: 614 o Autonomous System (AS) number 616 o Protocol-specific group identifiers, which expand to a set of IP 617 address ranges (CIDR) and/or AS numbers. In one specific solution 618 proposal, these are called Partition ID (PID). 620 5. Rating criteria 622 Rating criteria are used in the ALTO client protocol to express 623 topology- or connectivity-related properties, which are evaluated in 624 order to generate the ALTO guidance. The ALTO client protocol 625 specification defines a basic set of rating criteria, which have to 626 be suported by all implementations, and an extension procedure for 627 adding new criteria (see Section 3.1.3). The following list gives an 628 overview on further rating criteria that have been proposed in the 629 past, or which are in use by by ALTO-related prototype 630 implementations. This list is not intended as normative text. 631 Instead, the only purpose of the following list is to document the 632 rating criteria that have been proposed so far, and to solicit 633 further feedback and discussion: 635 5.1. Distance-related rating criteria 637 o Relative topological distance: relative means that a larger 638 numerical value means greater distance, but it is up to the ALTO 639 service how to compute the values, and the ALTO client will not be 640 informed about the nature of the information. One way of 641 generating this kind of information MAY be counting AS hops, but 642 when querying this parameter, the ALTO client MUST NOT assume that 643 the numbers actually are AS hops. 645 o Absolute topological distance, expressed in the number of 646 traversed autonomous systems (AS). 648 o Absolute topological distance, expressed in the number of router 649 hops (i.e., how much the TTL value of an IP packet will be 650 decreased during transit). 652 o Absolute physical distance, based on knowledge of the approximate 653 geolocation (continent, country) of an IP address. 655 5.2. Charging-related rating criteria 657 o Traffic volume caps, in case the Internet access of the resource 658 consumer is not charged by "flat rate". For each candidate 659 resource provider, the ALTO service could indicate the amount of 660 data that may be transferred from/to this resource provider until 661 a given point in time, and how much of this amount has already 662 been consumed. Furthermore, it would have to be indicated how 663 excess traffic would be handled (e.g., blocked, throttled, or 664 charged separately at an indicated price). The interaction of 665 several applications running on a host, out of which some use this 666 criterion while others don't, as well as the evaluation of this 667 criterion in resource directories, which issue ALTO queries on 668 behalf of other peers, are for further study. 670 5.3. Performance-related rating criteria 672 The following rating criteria are subject to the remarks below. 674 o The minimum achievable throughput between the resource consumer 675 and the candidate resource provider, which is considered useful by 676 the application (only in ALTO queries), or 678 o An arbitrary upper bound for the throughput from/to the candidate 679 resource provider (only in ALTO replies). This may be, but is not 680 necessarily the provisioned access bandwidth of the candidate 681 resource provider. 683 o The maximum round-trip time (RTT) between resource consumer and 684 the candidate resource provider, which is acceptable for the 685 application for useful communication with the candidate resource 686 provider (only in ALTO queries), or 688 o An arbitrary lower bound for the RTT between resource consumer and 689 the candidate resource provider (only in ALTO replies). This may 690 be, for example, based on measurements of the propagation delay in 691 a completely unloaded network. 693 The ALTO client MUST be aware, that with high probability, the actual 694 performance values differ significantly from these upper and lower 695 bounds. In particular, an ALTO client MUST NOT consider the "upper 696 bound for throughput" parameter as a permission to send data at the 697 indicated rate without using congestion control mechanisms. 699 The discrepancies are due to various reasons, including, but not 700 limited to the facts that 702 o the ALTO service is not an admission control system 704 o the ALTO service may not know the instantaneous congestion status 705 of the network 707 o the ALTO service may not know all link bandwidths, i.e., where the 708 bottleneck really is, and there may be shared bottlenecks 710 o the ALTO service may not know whether the candidate peer itself is 711 overloaded 713 o the ALTO service may not know whether the candidate peer throttles 714 the bandwidth it devotes for the considered application 716 o the ALTO service may not know whether the candidate peer will 717 throttle the data it sends to us (e.g., because of some fairness 718 algorithm, such as tit-for-tat) 720 Because of these inaccuracies and the lack of complete, instantaneous 721 state information, which are inherent to the ALTO service, the 722 application must use other mechanisms (such as passive measurements 723 on actual data transmissions) to assess the currently achievable 724 throughput, and it MUST use appropriate congestion control mechanisms 725 in order to avoid a congestion collapse. Nevertheless, these rating 726 criteria may provide a useful shortcut for quickly excluding 727 candidate resource providers from such probing, if it is known in 728 advance that connectivity is in any case worse than what is 729 considered the minimum useful value by the respective application. 731 5.4. Inappropriate rating criteria 733 Rating criteria that SHOULD NOT be defined for and used by the ALTO 734 service include: 736 o Performance metrics that are closely related to the instantaneous 737 congestion status. The definition of alternate approaches for 738 congestion control is explicitly out of the scope of ALTO. 739 Instead, other appropriate means, such as using TCP based 740 transport, have to be used to avoid congestion. 742 6. IANA Considerations 744 This requirements document does not mandate any immediate IANA 745 actions. However, such IANA considerations may arise from future 746 ALTO specification documents which try to meet the requirements given 747 here. 749 7. Security Considerations 751 High-level security considerations for the ALTO service can be found 752 in the "Security Considerations" section of the ALTO problem 753 statement [I-D.ietf-alto-problem-statement]. For a set of specific 754 security requirements please refer to Section 3.3 of this document. 756 8. References 758 8.1. Normative References 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, March 1997. 763 8.2. Informative References 765 [ALTO-charter] 766 Marocco, E. and V. Gurbani, "Application-Layer Traffic 767 Optimization (ALTO) Working Group Charter", February 2009. 769 [I-D.ietf-alto-problem-statement] 770 Seedorf, J. and E. Burger, "Application-Layer Traffic 771 Optimization (ALTO) Problem Statement", 772 draft-ietf-alto-problem-statement-04 (work in progress), 773 September 2009. 775 [I-D.kiesel-alto-3pdisc] 776 Kiesel, S. and M. Tomsu, "Third-party ALTO server 777 discovery", draft-kiesel-alto-3pdisc-00 (work in 778 progress), August 2009. 780 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 781 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 782 RFC 4787, January 2007. 784 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 785 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 786 RFC 5382, October 2008. 788 Appendix A. Contributors 790 The authors were supported by the following people, who have 791 contributed to this document: 793 o Zoran Despotovic 795 o Jason Livingood 797 o Saverio Niccolini 799 o Jan Seedorf 801 o Martin Stiemerling 803 The authors would like to thank the members of the P2PI and ALTO 804 mailing lists for their feedback. 806 Appendix B. Acknowledgments 808 The authors would like to thank 810 o Vijay K. Gurbani 812 o Enrico Marocco 814 for fostering discussions that lead to the creation of this document, 815 and for giving valuable comments on it. 817 Sebastian Kiesel, Saverio Niccolini, Jan Seedorf, and Martin 818 Stiemerling are partially supported by the NAPA-WINE project 819 (Network-Aware P2P-TV Application over Wise Networks, 820 http://www.napa-wine.org), a research project supported by the 821 European Commission under its 7th Framework Program (contract no. 822 214412). The views and conclusions contained herein are those of the 823 authors and should not be interpreted as necessarily representing the 824 official policies or endorsements, either expressed or implied, of 825 the NAPA-WINE project or the European Commission. 827 Laird Popkin and Y. Richard Yang are grateful to the many 828 contributions made by the members of the P4P working group and Yale 829 Laboratory of Networked Systems. The P4P working group is hosted by 830 DCIA. 832 Authors' Addresses 834 Sebastian Kiesel (editor) 835 NEC Europe Ltd., Network Laboratories Europe 836 Kurfuersten-Anlage 36 837 Heidelberg 69115 838 Germany 840 Phone: +49 6221 4342 232 841 Email: sebastian.kiesel@nw.neclab.eu 843 Laird Popkin 844 Pando Networks, Inc. 846 Email: laird@pando.com 848 Stefano Previdi 849 Cisco Systems, Inc. 851 Email: sprevidi@cisco.com 853 Richard Woundy 854 Comcast Corporation 856 Email: Richard_Woundy@cable.comcast.com 858 Yang Richard Yang 859 Yale University 861 Email: yry@cs.yale.edu