idnits 2.17.1 draft-saumitra-alto-queryresponse-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.ii 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 27 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2009) is 5532 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '16' is mentioned on line 649, but not defined == Unused Reference: '15' is defined on line 996, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-marocco-alto-problem-statement-04 ** Downref: Normative reference to an Informational draft: draft-marocco-alto-problem-statement (ref. '1') == Outdated reference: A later version (-02) exists of draft-kiesel-alto-reqs-01 ** Downref: Normative reference to an Informational draft: draft-kiesel-alto-reqs (ref. '2') -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-22) exists of draft-ietf-p2psip-diagnostics-00 ** Obsolete normative reference: RFC 2818 (ref. '6') (Obsoleted by RFC 9110) == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-01 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Das 3 Internet-Draft V. Narayanan 4 Intended status: Standards Track Qualcomm, Inc. 5 Expires: September 5, 2009 March 4, 2009 7 A Client to Service Query Response Protocol for ALTO 8 draft-saumitra-alto-queryresponse-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 5, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 This document may contain material from IETF Documents or IETF 45 Contributions published or made publicly available before November 46 10, 2008. The person(s) controlling the copyright in some of this 47 material may not have granted the IETF Trust the right to allow 48 modifications of such material outside the IETF Standards Process. 49 Without obtaining an adequate license from the person(s) controlling 50 the copyright in such materials, this document may not be modified 51 outside the IETF Standards Process, and derivative works of it may 52 not be created outside the IETF Standards Process, except to format 53 it for publication as an RFC or to translate it into languages other 54 than English. 56 Abstract 58 ALTO aims to improve the peer selection in applications that have a 59 choice to transfer data from multiple data resources. This draft 60 presents a protocol for a flexible and extensible query response 61 protocol between an ALTO aware client and ALTO service provider. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. ALTO Query Response Protocol . . . . . . . . . . . . . . . . . 4 68 3.1. ALTO Service Configuration . . . . . . . . . . . . . . . . 5 69 3.2. ALTO Service Discovery . . . . . . . . . . . . . . . . . . 7 70 3.3. ALTO Service Contact . . . . . . . . . . . . . . . . . . . 8 71 3.4. ALTO Message Formats . . . . . . . . . . . . . . . . . . . 8 72 3.4.1. Presentation Language . . . . . . . . . . . . . . . . 9 73 3.4.2. Common Header . . . . . . . . . . . . . . . . . . . . 9 74 3.4.3. Message Contents Format . . . . . . . . . . . . . . . 10 75 3.4.4. Response Codes and Response Errors . . . . . . . . . . 11 76 3.4.5. Location Context Query and Response . . . . . . . . . 12 77 3.4.6. Guidance Query and Response . . . . . . . . . . . . . 15 78 4. Example Use By An Application . . . . . . . . . . . . . . . . 18 79 5. Requirements Matching . . . . . . . . . . . . . . . . . . . . 19 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 88 1. Introduction 90 Internet traffic is dominated today by P2P (peer-to-peer) 91 applications used for file transfer, voice communication and live 92 streaming. Such an architecture for data transfer is attractive 93 because it reduces the bandwidth costs of the content provider since 94 they simply need to seed the content to a few nodes in the network 95 which would then contribute upload bandwidth to assist the content 96 provider's servers in the data transfer. Thus, the single point 97 bottleneck at the content provider is eliminated and both users and 98 content providers benefit. 100 However such an approach is detrimental to the other important entity 101 in the system: the ISPs. While p2p has led to the increased 102 popularity of broadband connections and arguably increased 103 subscribers for ISPs; it has also increased traffic costs for the 104 ISPs. This is because P2P application's peer selection does not 105 consider underlying network topology and link costs in that topology. 106 Most p2p applications typically are only interested in improving 107 their data transfer performance which is satisfied if the download 108 link of the user is saturated. As shown in [10], traffic generated 109 by popular P2P applications often cross network boundaries multiple 110 times, overloading links which are frequently subject to congestion 111 [11]. This happens because most p2p applications simply use random 112 peer selection followed by monitoring and reevaluation. Even if p2p 113 applications perform some network measurements, these typically tend 114 to be round trip time estimation which may or may not lead to peer 115 selection conducive to ISP interests. 117 This led to ISPs efforts at shaping or blocking P2P traffic on 118 specific ports. In response, p2p applictions started using dynamic 119 ports to transfer data following whcih ISPs had to use deep packet 120 protocol specific information to shape p2p flows. In response, p2p 121 applications have started encrypting their connections. The use of 122 TCP RST messages to deter costly p2p application data transfer has 123 led to the network neutrality debate as well. It is in the ISPs 124 interests to avoid the cat-and-mouse games of protocol-specific 125 detection and mitigation while still not having to increase costs 126 significantly to accomodate p2p traffic. 128 One way to reduce the impact on ISPs would be the deployment of 129 caching entities in the networks to reduce cross-ISP traffic and 130 network distance of data transfer. However such an approach has 131 several issues: (1) It is not clear who would deploy these high- 132 bandwidth large-storage capable caches since it can be argued that 133 caching pushes the costs from the content provider to the ISPs and. 134 (2) The caches would need to be able to cache data from all p2p 135 applications and consequently become complicated to deploy and 136 maintain over time as p2p application evolve. This is specially 137 difficult due to the heavy tailed nature of p2p content. (3) The use 138 of caches opens up the issue of storage of illegal and copyrighted 139 content. Thus, a solution is needed that can allow for peer 140 selection by the p2p application themselves that is friendly to the 141 ISPs network costs while being friendly to the application's 142 objective of good performance for the user. 144 Recent studies [12], [13], [14] have suggested that it may be 145 possible to reduce the impact that P2P applications have on ISPs 146 traffic costs. This is mainly achieved by informed peer selection in 147 the P2P applications guided by network level metrics instead of 148 random selection. However, p2p applications do not have a trust 149 relationship with network operators and what may be good for the ISP 150 is not necessarily good for the performance of the p2p applications. 151 This creates a tension between these two competing interests and a 152 solution for peer selection needs to address the interests of both 153 the entities in the system. The ALTO working group aims to enable 154 solutions that addresses this tension. It improves peer selection 155 while being ISP friendly. The problem statement of ALTO is described 156 in [1]. The current set of requirements is discussed in [2]. 158 This document describes an ALTO client to service query response 159 protocol optimizing traffic generated by P2P applications using 160 information provided by third parties, i.e. the other peers in the 161 network (through an aggregator ALTO service) or the network operator. 162 The overall goal of optimizing the P2P application is for them to 163 become more network-friendly, while at the same time allowing the 164 networks to remain application-friendly. 166 The client query response protocol is designed to be flexible and 167 extensible for multiple aspects of the peer selection problem. such 168 as FTP and HTTP replicas, locality aware neighbor selection in DHTs 169 etc. It is also designed to be able to address peer selection that 170 is ISP-centric as well as peer-centric. 172 2. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [3]. 178 3. ALTO Query Response Protocol 180 The basic setting for the query response protocol is as follows: The 181 ALTO ecosystem addressed by this draft includes an ALTO client that 182 makes a query and an ALTO service running on an ALTO server that 183 provides a response. Note that the ALTO client can make a query for 184 itself or another client. 186 In the remaining sections we discuss how to discover an ALTO service, 187 communicate with an ALTO service; message formats for querying an 188 ALTO service and for responding to an ALTO query 190 The protocol operates over a single given interface at a time. The 191 whole procedure can be repeated for a different interface. Each 192 interface on a multihomed host may require the discovery of a 193 different ALTO service (since the ISPs on each interface may be 194 different). The peer selection is also dependent on the interface. 195 Hence the protocol is meant to operate per interface. Any peer 196 selection algorithms that work across interfaces would need to 197 perform ALTO query reponse on each interface and use its own 198 algorithm to decide which peer to connect to on which interface. 200 OPEN ISSUE: detecting interfaces with Internet connectivity. 202 3.1. ALTO Service Configuration 204 Some mechanisms for ALTO service discovery are described in this 205 section. 207 This specification defines a new content type "application/ 208 p2p-alto+xml" for an MIME entity that contains alto information. An 209 example document is shown below. 211 212 213 214 215 216 217 218 220 Figure 1: ALTO Service Configuration Document 222 The file MUST be a well formed XML document and it SHOULD contain an 223 encoding declaration in the XML declaration. If the charset 224 parameter of the MIME content type declaration is present and it is 225 different from the encoding declaration, the charset parameter takes 226 precedence. Every application conforment to this specification MUST 227 accept the UTF-8 character encoding to ensure minimal 228 interoperability. The namespace for the elements defined in this 229 specification is urn:ietf:params:xml:ns:p2p:alto. 231 The file can contain multiple "alto" elements where each one contains 232 the configuration information for a different ALTO service. Each 233 "alto" has the following attributes: 235 o instance-name: name of the overlay 237 o expiration: time in future at which this alto configuration is no 238 longer valid and need to be retrieved again. This is expressed in 239 seconds from the current time. 241 o Inside each alto element, the following elements can occur: 243 * alto-server This element contains the URI at which the ALTO 244 server can be reached in a "uri" element. This URI is based on 245 the syntax defined in [4]. More than one alto-server element 246 may be present for load balance. The client can choose any one 247 at random. The ALTO server may be running on a public IP 248 address or be accessible via an overlay. 250 * OPEN ISSUE: Make p2p URIs flexible enough to allow the ALTO 251 service to be pointed to by an ip address and port number as 252 well as a node id on an overlay. This enables an overlay based 253 ALTO server as well as a more traditional model of a publicly 254 available ALTO server. Draft [4] revisions will address this 255 issue. 257 * location-context This element represents (if set to true) that 258 the ALTO service mandates a location context query (defined in 259 Section Section 3.4.5) prior to a guidance query. 261 * metric-supported This element represents a metric supported by 262 the ALTO service. It has an attribute called "name" that 263 represents the name of the metric such as latency, bandwidth, 264 reliability). A set of metrics and their units should be 265 standardized and MUST be understood by ALTO clients. More than 266 one metric-supported element may be present. 268 OPEN ISSUE: Which metrics should be standardized and what units 269 should be used for referring to them as well as an accepted 270 definition of what the units mean. Some important ones are listed 271 below as a starting point. Applications MUST understand these basic 272 set of metrics as well as typical values to use in queries. 274 o name = "bandwidth", unit = "kbps" 275 o name = "latency", unit = "msec", description = "A measure of the 276 round trip time that is likely between client and a peer" 278 o name = "pDistance", unit = "scalar" 280 o name = "uptime", unit = "sec" 282 o name = "loss", unit = "scalar" 284 o name = "ASDistance", unit = "scalar" 286 TODO: Sync these metrics with what is defined for p2psip diagnostics 287 ([5] as well as the various proposals on ISP aided peer selection. 288 For example having support for a metric such as pDistance would be 289 useful for many different proposals on ISP aided peer selection. The 290 metrics used in p2psip diagnostics may be metrics that are useful to 291 aggregate at an ALTO service in an overlay. This service can then 292 provide ALTO clients with peer selection guidance. 294 3.2. ALTO Service Discovery 296 When a client first wishes to use an ALTO service, it starts with a 297 discovery process to find a server for the ALTO service. The peer 298 first determines the ALTO service name. This value is provided by 299 the user or some other out of band provisioning mechanism. If the 300 name is an IP address, that is directly used otherwise the peer MUST 301 do a DNS SRV query using a Service name of "alto_discover" and a 302 protocol of tcp to find an ALTO server. 304 Once an address for the ALTO server is determined, the peer forms an 305 HTTPS connection to that IP address. The certificate MUST match the 306 overlay name as described in [6]. 308 Whenever a peer contacts the ALTO server, it MUST fetch a new copy of 309 the ALTO configuration file. To do this, the peer performs a GET to 310 the URL formed by appending a path of "/alto/enroll" to the alto 311 service URI. For example, if the ALTO service name was example.com, 312 the URL would be "https://example.com/alto/enroll". The result is an 313 XML configuration file described above, which replaces any previously 314 learned configuration file for this ALTO service. 316 OPEN ISSUE: performing ALTO service discovery in the context of a 317 overlay (.e. using p2psip). This could be similar to the mechanisms 318 presented for TURN server discovery in [7]. 320 3.3. ALTO Service Contact 322 ALTO client and server MUST use TLS for their communication. The 323 ALTO client contacts the ALTO server using the URI in the ALTO 324 configuration document. 326 The following modes can be used for ALTO client-server communication 328 Method 1: use a shared key between the ALTO client and ALTO server to 329 set up the TLS session. 331 Method 2: use server side authentication. 333 Method 3: use TLS-PSK with an out of band provisioned password. This 334 allows tiered guidance delivery to different clients. Using this 335 method, ALTO servers can limit participation, provide QoS to 336 different levels of users, and prevent misuse and overuse of the ALTO 337 service 339 TODO: Including service contact method information in the ALTO 340 configuration document. 342 3.4. ALTO Message Formats 344 The ALTO client to service protocol is a message-oriented request/ 345 response protocol. The messages are encoded using binary fields. 346 All integers are represented in network byte order. 348 Each message has three parts, concatenated as shown below: 350 +-------------------------+ 351 | Common Header | 352 +-------------------------+ 353 | Message Contents | 354 +-------------------------+ 356 Figure 2: ALTO Packet 358 The contents of these parts are as follows: 360 o Common Header: Each message has a generic header. 362 o Message Contents: The message being delivered between the client 363 and the ALTO service. 365 The following sections describe the format of each part of the 366 message. 368 3.4.1. Presentation Language 370 The structures defined in this document are defined using a C-like 371 syntax based on the presentation language used to define TLS. This 372 notation is borrwed from the p2psip reload draft [7]. 374 o All lengths are denoted in bytes, not objects. 376 o Variable length values are denoted like arrays with angle 377 brackets. 379 o "select" is used to indicate variant structures. 381 For instance, "uint16 array(0..2^8-2)" represents up to 254 bytes but 382 only up to 127 values of two bytes (16 bits) each. 384 An enum represents an enumerated type. The values associated with 385 each possibility are represented in parentheses and the maximum value 386 is represented as a nameless value, for purposes of describing the 387 width of the containing integral type. For instance, Boolean 388 represents a true or false: 390 enum { false (0), true(1), (255)} Boolean; 392 A boolean value is either a 1 or a 0 and is represented as a single 393 byte on the wire. 395 3.4.2. Common Header 397 struct { 398 uint8 version; 399 uint24 length; 400 CommonOptions options[options_length]; 401 } CommonHeader; 403 Figure 3: ALTO Common Header 405 The contents of the structure are: 407 o version The version of the ALTO protocol being used. This 408 document describes version 0.1, with a value of 0x01. 410 o length The count in bytes of the size of the message, including 411 the header. 413 o options Contains a series of CommonOptions entries 415 3.4.2.1. Common Header Options 417 The common header can be extended with forwarding header options, 418 which are a series of CommonOptions structures: 420 enum { (255) } CommonOptionsType; 421 struct { 422 CommonOptionsType type; 423 uint16 length; 424 select (type) { /* Option values go here */ } option; 425 } CommonOption; 427 Figure 4: ALTO Common Header Options 429 The contents of the structure are: 431 o type The type of the option. 433 o length The length of the rest of the structure. 435 o option The option value 437 3.4.3. Message Contents Format 439 struct { 440 MessageCode message_code; 441 opaque payload<0..2^24-1>; 442 } MessageContents; 444 Figure 5: ALTO Message Payload 446 The contents of this structure are as follows: 448 o message_code This indicates the message that is being sent. The 449 code space is broken up as follows. 451 * 0 Reserved 453 * 1 .. 0x7fff Requests and responses. These code points are 454 always paired, with requests being odd and the corresponding 455 response being the request code plus 1. Thus, "location_query" 456 (the query) has value 1 and "location_answer" (the response) 457 has value 2 459 * 0xffff Error 461 o message_body The message body itself, represented as a variable- 462 length string of bytes. The bytes themselves are dependent on the 463 code value. The next few sections describe the different ALTO 464 methods used in the payload definition. 466 3.4.4. Response Codes and Response Errors 468 An ALTO server processing a request returns its status in the 469 message_code field. If the request was a success, then the message 470 code is the response code that matches the request (i.e., the next 471 code up). The response payload is then as defined in the request/ 472 response descriptions. 474 If the request failed, then the message code is set to 0xffff (error) 475 and the payload MUST be an error_response PDU, as shown below. 477 When the message code is 0xffff, the payload MUST be an 478 ErrorResponse. 480 struct { 481 uint16 error_code; 482 opaque error_info<0..2^16-1>; 483 } ErrorResponse; 485 Figure 6: ALTO Response Error 487 The contents of this structure are as follows: 489 o error_code A numeric error code indicating the error that 490 occurred. 492 o error_info A free form text string indicating the reason for the 493 response for diagnostic purposes. 495 The following error code values are defined. 497 o Error_unauthorized: The client was not authorized to use the ALTO 498 service. 500 o Error_hla_not_found: The host location attribute (client location 501 context) provided was invalid. 503 o Error_overload: The ALTO service is currently overloaded with 504 requests and cannot respond. Clients SHOULD implement an 505 algorithm such as binary exponental backoff when restablishing 506 contact with the ALTO service. 508 o Error_option_not_found: An option header was not found. 510 o Error_metric_not_found: A metric requested in the query was not 511 understood by the ALTO service. 513 o Error_no_matches: No peers matched the query. 515 TODO: Make sure the list of errors are comprehensive. 517 3.4.5. Location Context Query and Response 519 An ALTO service may need to set a location context for a client prior 520 to the client sending a guidance query. ALTO services MUST choose 521 whether to require a location context query or not in the ALTO 522 configuration document. If the ALTO location-context filled in the 523 configuration document is set to true, then a querying host MUST 524 perform a location context query. 526 3.4.5.1. Location Context Query 528 The location query message MUST contain a precision value specifying 529 high precision (0x01), medium precision (0x02) or low precision 530 (0x03). The ALTO service MAY choose to use this precision in 531 determining a location context for the querying host. For example 532 higher precision query would assign a more accurate location context 533 to the querying host possibly consuming more resources in making that 534 determination at the ALTO service. 536 struct { 537 uint8 precision; 538 } LocationQuery; 540 Figure 7: ALTO Query 542 3.4.5.2. Location Context Response 544 A response to an ALTO location context query contains the 545 HostLocationAtttribute of the querying host. This host location 546 attribute identifies the querying host in the topology. It is 547 flexible enough to allow an ALTO service to determine the parition id 548 of a host in P4P and return it, determine the external IP address and 549 return it etc. 551 The host location attribute MUST be used in a guidance query. 553 struct { 554 HostLocationAttribute hla; 555 } Response; 557 Figure 8: ALTO Response 559 The host location attribute is represented as shown below and can be 560 either an ipv4 address, ipv6 address, overlay node identifer or 561 partition identifier. This allows for referring to nodes in a 562 flexible manner. For example, a host can perform an ALTO query to an 563 overlay based ALTO service and refer to the peers to obtain guidance 564 for, using node identifiers that make sense on the overlay. 566 enum {reserved_addr(0), ipv4_address (1), ipv6_address (2), node_address (3), partition_id(4), 567 (255)} HostLocationAttributeType; 569 struct { 570 uint32 addr; 571 } IPv4Addr; 573 struct { 574 uint128 addr; 575 } IPv6Addr; 577 typedef opaque OverlayNodeAddr[16]; 579 typedef opaque ISPPartitionAddr[16]; 581 struct { 582 AddressType type; 583 uint8 length; 585 select (type) { 586 case ipv4_address: 587 IPv4Addr v4addr; 589 case ipv6_address: 590 IPv6Addr v6addr; 592 case node_address: 593 OverlayNodeAddr nodeaddr; 595 case partition: 596 ISPPartitionAddr partitionaddr; 598 /* This structure can be extended */ 600 } HostLocationAttribute; 602 Figure 9: Host Location Attribute Representation 604 As shown in the Figure Figure 9, a host location attribute can encode 605 ip addresses, node addresses or partition ids. 607 OverlayNodeAddr and ISPPartitionAddr are fixed-length 128-bit 608 structures represented as a series of bytes, most significant byte 609 first. 611 TODO: Make sure this is extensible enough to accomodate the needs to 612 different ALTO proposals. 614 3.4.5.3. Obtaining the external address on an interface 616 If the ALTO location-context filled in the configuration document is 617 set to false, a querying host MUST obtain the external address on the 618 interface for which the host needs guidance using either of the two 619 methods defined below. 621 Method 1: The querying host SHOULD use the Session Traversal 622 Utilities for NAT (STUN) [8] to determine a public IP address. If 623 using this method, the host MUST the "Binding Request" message and 624 the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the 625 response. Using STUN requires cooperation from a publicly accessible 626 STUN server. Thus, the host also requires configuration information 627 that identifies the STUN server, or a domain name that can be used 628 for STUN server discovery. To be selected for this purpose, the STUN 629 server needs to provide the public reflexive transport address of the 630 host. 632 Method 2: The querying host may contact a predefined publicly 633 accessible host configured to respond to a UDP packet on a predefined 634 port; the data of the response could contain the source IP address 635 that was in the request. Alternatively, a HTTP server at a 636 particular URL could be configured to respond to a GET request with a 637 "text/plain" body containing the IP address of the requester. 638 However, transparent HTTP proxies can reduce the effectiveness of 639 this method. 641 3.4.6. Guidance Query and Response 643 Once a host location attribute is obtained either using external 644 address discovery or a location context query, a guidance query can 645 now be issued to the ALTO server. 647 3.4.6.1. Guidance Query 649 typedef opaque ObjectId[16]; 651 struct{ 652 uint8 metricname; 653 uint8 operator; 654 uint16 value; 655 }MetricData; 657 struct { 658 ObjectId oid; 659 HostLocationAttribute clienthla; 660 uint8 precision; 661 MetricData metrics<0..2^32-1> 662 HostLocationAttribute destinations<0..2^32-1>; 663 } Query; 665 Figure 10: ALTO Guidance Query 667 The ALTO guidance query is structured as follows: 669 o clienthla: The host location attribute of the client. This need 670 not be the same as the actual query host. This allows a third 671 party to query on behalf on another host. This MUST be specified 672 in the query. 674 o precision: This defines the precision of ALTO guidance required by 675 the client. Current this supports three values: 0x01 for high, 676 0x02 for medium, 0x03 for low. ALTO server MAY choose to use more 677 complex or less complex guidance algorithms on the backend for 678 different precisions requested. The ALTO client MUST define a 679 value for this field. 681 o metrics: This is a ranked list of constraints that denotes the 682 interest of the client. Each metric constraint contains a metric, 683 operator and value. The metricname is one of the standardized 684 metric names supported by the specific ALTO service as defined in 685 the ALTO configuration document. The operator field defines four 686 values: 0x01 for less than, 0x02 for approximately equal to 687 (within 10% of), 0x03 for greater than, 0x04 for NA. An operator 688 of NA means that the querying host wants guidance on the metric 689 but has no constraint on the metric value. 691 o destinations: This is a list of peers the querying host wishes to 692 select from. The destinations are a list of host location 693 attributes. 695 o oid: This is an optional field containing the object identifier 696 the query host is aiming to transfer over the network. The 697 querying host MAY choose to include this field and the ALTO server 698 MAY choose to use it. This field allows ALTO services that manage 699 object caches to include them in the guidance response by matching 700 the oid. For example a querying host may only know 5 sources of 701 an objects that are all interdomain sources of an object. If the 702 oid is specified, the ALTO server could include network caches 703 that match the query constraints in the list of peers returned to 704 the querying host. 706 OPEN ISSUE: can we have a widely accepted method of generating the 707 oid which makes referencing objects and identifying additional peers 708 with the object easier. One method to use for generating the oid is 709 content-based naming where the oid is the cryptographic hash of the 710 object data. Similar techniques have been proposed for data oriented 711 data transfer recently (e.g. Data Oriented Transfer and Data 712 Oriented Network Architecture) 714 3.4.6.2. Guidance Response 716 The ALTO guidance response contains a ranked list of peers (resource 717 owners) matching the query contrainsts. The query constraints MUST 718 take preference in terms of their order in the query. Each item in 719 the list MUST be the host location attribute of the peer, its 720 associated metric and a lifetime value corresponding to the number of 721 seconds this information is valid. This allows caching of peer 722 selection guidance for repeated accesses to the same object by the 723 client applications on the querying host. The ALTO service MAY 724 choose to simply provide a ranking preserving the query constraints 725 without revealing metric values. 727 struct { 728 HostLocationAttribute hla; 729 MetricData metrics<0..2^8-1>; 730 uint16 lifetime; 731 } ResourceOwnerMetric; 733 struct { 734 ResourceOwnerMetric selection<0..2^32-1> 735 } Response; 736 Figure 11: ALTO Guidance Response 738 4. Example Use By An Application 740 This section extends a use case and example proposed in [9] and shows 741 how the use case fits this proposed protocol. 743 Consider a BitTorrent client that wishes to use the ALTO information. 744 The client will have a list of perhaps up to 200 initial candidate 745 peers, out of which it will select perhaps 50 peers to try to connect 746 to. In an initial implementation, the client could: 748 Use the ALTO query protocol with metric of latency less than 50ms as 749 the first metric constraint and pDistance NA as the second query 750 constraint. This query can be sent out to the ALTO service and a 751 response received which will contain all peers ranked in terms of 752 their latency followed by their pDistance. 754 Split the candidates into three sets: preferred (those with low 755 latency and high pDistance values), to-be-avoided (those with low 756 latency and low pDistance values), and default (high latency and high 757 pDistance values) 759 Select up to 25 candidates randomly from the preferred set. In 760 particular, if there are fewer than 25 in the preferred set, select 761 them all. 763 Fill remaining slots up to 50 with candidates from the default set. 765 If this didn't fill the slots (i.e., fewer than 50 of the candidates 766 were in the union of preferred and default sets), fill the rest by 767 candidates from the to-be-avoided set. 769 When establishing connections after the initial startup, continue 770 using the policy of giving up to half the slots to preferred with the 771 rest for default and to-be-avoided only as last resort. 773 When selecting a peer to optimistically unchoke, half the time select 774 a preferred peer if there is one. 776 (The particular numbers could be different.) If the preferred peers 777 perform better than default ones, they will dominate the transfers. 778 To-be-avoided peers are largely not contacted, unless the prohibitive 779 policy is broad enough or the swarm is small enough that it is 780 necessary to contact them to fill the slots. 782 5. Requirements Matching 784 This section outlines how the proposed protocol meets ALTO query 785 response requirements. 787 o REQ. 1: The ALTO service MUST implement one or several well- 788 defined interfaces, which can be queried from ALTO clients. - This 789 draft present one defined query response interface. 791 o REQ. 2: The ALTO clients MUST be able to query information from 792 the ALTO service, which provides guidance for selecting 793 appropriate resource providers. - This draft allows the ALTO 794 service to provide guidance on selecting resource providers. 796 o REQ. 3: ALTO clients MUST be able to find out where to send ALTO 797 queries - This draft defines some mechanisms for ALTO service 798 discovery. 800 o REQ. 4: One mode of ALTO operation is that ALTO clients may be 801 embedded directly in the resource consumer (e.g., peer of an 802 unstructured P2P application), which wants to access a resource. - 803 This draft does not mandate anything about the locations of ALTO 804 clients and servers. The goal of the draft is to allow ALTO 805 client and servers to be servers in the cloud, peers in an overlay 806 or just IP endpoints. 808 o REQ. 5: The syntax and semantics of the ALTO protocol MUST be 809 extensible to allow the requirements of future applications to be 810 adopted. - This draft attempts to make the query and response 811 mechanisms generic to achieve this. 813 o The information available from the ALTO service is not a 814 replacement for congestion control mechanisms. Applications using 815 ALTO MUST ensure that they do not cause congestion in the network, 816 e.g., by using TCP transport, which includes congestion control 817 mechanisms. - This draft specifies the use of TCP. 819 o REQ. 7: Any application designed to use ALTO MUST also work 820 reasonably if no ALTO servers can be found or if no responses to 821 ALTO queries are received. - No requirement that ALTO be used or 822 responses received in this draft. 824 o REQ. 8: An overloaded ALTO server receiving too many requests MAY 825 silently discard excess requests.- Server endpoint behavior is not 826 included in this version of the draft. There is not requirement 827 to respond. 829 o REQ. 9: An ALTO client MAY retransmit an unanswered ALTO query 830 after a reasonable amount of time, or it MAY query a different 831 server. - Client endpoint behavior is not included in this version 832 of the draft. 834 o REQ. 10: An ALTO client MUST limit the total number of unanswered 835 ALTO queries on a per-server basis. - Client endpoint behavior is 836 not included in this version of the draft. 838 o REQ. 11: If an ALTO query cannot be sent because the maximum 839 number of outstanding queries is reached, the ALTO client MAY wait 840 for some time. Then, if it is still not possible to send the 841 query, it MUST report to the application that no ALTO information 842 is available. - This is an implementation detail of the ALTO 843 client. An error response exists to specify overload. 845 o REQ. 12: An ALTO server, which is operating close to its capacity 846 limit, SHOULD be able to inform clients about its impending 847 overload situation, even if it has not yet to discard excess query 848 messages. - The overload error response achieves this purpose. 850 o REQ. 13: The ALTO protocol MAY have a mechanism by which the ALTO 851 client can specify the required level of precision. - This draft 852 allows a coarse level of precision requested to be included in the 853 query. The ALTO service MAY choose to use the precision. 855 o REQ. 14: The ALTO protocol SHOULD support lifetime attributes, to 856 enable caching of recommendations at ALTO clients.- This draft has 857 support for lifetime attributes. 859 o REQ. 15: The ALTO protocol MUST be designed in a way that the ALTO 860 service can be provided by an operator which is not the operator 861 of the IP access network. - There is no requirement for the ALTO 862 service to be tied to the querying host's ISP although they are 863 likely to have the best information from a network impact point of 864 view. 866 o REQ. 16: Different instances of the ALTO service operated by 867 different providers must be able to coexist. - Any ALTO service 868 that can understand the query and provide an ALTO configuration 869 document can provide an ALTO service. 871 o REQ. 17: The ALTO protocol MUST support mechanisms for mutual 872 authentication and authorization of ALTO clients and servers. - 873 This draft specifies some mechanisms to achieve this. 875 o REQ. 18: The ALTO protocol MUST support different levels of detail 876 in queries and responses, in order for the operator of an ALTO 877 service to be able to control how much information (e.g., about 878 the network topology) is disclosed. - The ALTO service need only 879 provide a ranking without specifying metrics in the guidance 880 response it is chooses to. 882 o REQ. 19: The ALTO protocol MUST support different levels of detail 883 in queries and responses, in order to protect the privacy of 884 users, to ensure that the operators of ALTO servers and other 885 users of the same application cannot derive sensitive information. 886 - This requirement is not very clearly defined. 888 o REQ. 20: One ALTO interface SHOULD be defined in a way, that the 889 operator of one ALTO server cannot easily deduce the resource 890 identifier (e.g., file name in P2P file sharing) which the 891 resource consumer seeking ALTO guidance wants to access. - The 892 object id is an optional field in the query. If an ALTO service 893 provider is deploying caches and p2p applications wish to gain 894 from using them, they can optinally specify the object id. 896 o REQ. 21: If the ALTO protocol supports including privacy-sensitive 897 information (such as resource identifiers or transport addresses) 898 in the ALTO queries or replies, the protocol MUST also support 899 encryption, in order to protect the privacy of users with respect 900 to third parties. - This draft proposes using TLS to secure the 901 channel between the client and server. 903 o REQ. 22: The ALTO protocol MUST include appropriate mechanisms to 904 protect the ALTO service against DoS attacks - This issue is still 905 open. If clients cooperate with the overlay error response DoS 906 should not be a threat. Generic DoS mitigation for an ALTO server 907 is a much bigger problem and out of scope of this draft. 909 6. Security Considerations 911 An entity could use the ALTO service to map out and ISPs preferences 912 and potentially reverse engineer some information about its topology. 913 This would require querying the ISP ALTO service from multiple 914 vantage points. An ISP could limit queries made on behalf of other 915 nodes from an entity to a smaller amount or slightly obfuscate/ 916 randomize its responses to sometimes give higher metric values to 917 peers in order to thwart such efforts. 919 This initial draft does not look in detail at security considerations 920 apart from that mentioned above. Future revisions will contain more 921 details. 923 7. IANA Considerations 925 TODO. 927 8. Acknowledgments 929 The author would like to thank Vidya Narayanan, Lakshminath Dondeti, 930 Enrico Marocco, Vijay Gurbani, Jon Peterson for discussions that 931 helped this draft. The draft was influenced by work being done in 932 the P2PSIP WG. 934 9. References 936 9.1. Normative References 938 [1] Seedorf, J. and E. Burger, "Application-Layer Traffic 939 Optimization (ALTO) Problem Statement", 940 draft-marocco-alto-problem-statement-04 (work in progress), 941 February 2009. 943 [2] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, 944 "Application-Layer Traffic Optimization (ALTO) Requirements", 945 draft-kiesel-alto-reqs-01 (work in progress), November 2008. 947 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 948 Levels", BCP 14, RFC 2119, March 1997. 950 [4] Hardie, T., "Mechanisms for use in pointing to overlay 951 networks, nodes, or resources", 952 draft-hardie-p2poverlay-pointers-00 (work in progress), 953 January 2008. 955 [5] Yongchao, S. and X. Jiang, "Diagnose P2PSIP Overlay Network", 956 draft-ietf-p2psip-diagnostics-00 (work in progress), 957 January 2009. 959 [6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 961 [7] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. 962 Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base 963 Protocol", draft-ietf-p2psip-base-01 (work in progress), 964 December 2008. 966 [8] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 967 Traversal Utilities for (NAT) (STUN)", 968 draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008. 970 [9] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 971 Export Service", draft-shalunov-alto-infoexport-00 (work in 972 progress), October 2008. 974 9.2. Informative References 976 [10] Karagiannis, T., Rodriguez, P., and K. Papagiannaki, "Should 977 ISPs fear Peer-Assisted Content Distribution?", IMC Proceedings 978 of the Internet Measurement Conference, 2005. 980 [11] Akella, A., Seshan, S., and A. Shaikh, "An Empirical Evaluation 981 of WideArea Internet Bottlenecks", Proceedings of ACM SIGCOMM, 982 2003. 984 [12] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and 985 P2P systems co-operate for improved performance?", ACM SIGCOMM 986 Computer Communications Review (CCR), 37:3, pp. 29-40, 2006. 988 [13] Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang, 989 "P4P: Explicit Communications for Cooperative Control Between 990 P2P and Network Providers", Proceedings of ACM SIGCOMM, 2008. 992 [14] Choffnes, D. and F. Bustamante, "Taming the Torrent: A 993 practical approach to reducing cross-ISP traffic in P2P 994 systems", Proceedings of ACM SIGCOMM, 2008. 996 [15] Madhyastha, H., Isdal, T., Piatek, M., Dixon, C., Anderson, T., 997 Krishnamurthy, A., and A. Venkataramani, "iPlane: an 998 information plane for distributed services", Proceedings of 999 USENIX OSDI, 2006. 1001 Authors' Addresses 1003 Saumitra M. Das 1004 Qualcomm, Inc. 1005 3195 Kifer Road 1006 Santa Clara, CA 1007 USA 1009 Phone: +1 408-533-9529 1010 Email: saumitra@qualcomm.com 1011 Vidya Narayanan 1012 Qualcomm, Inc. 1013 5775 Morehouse Dr 1014 San Deigo, CA 1015 USA 1017 Phone: +1 858-845-2483 1018 Email: vidyan@qualcomm.com