idnits 2.17.1 draft-kiesel-alto-3pdisc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 177 has weird spacing: '...art for resou...' -- The document date (March 8, 2010) is 5161 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: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-02 == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-03 == Outdated reference: A later version (-02) exists of draft-kiesel-alto-h12-01 == Outdated reference: A later version (-03) exists of draft-song-alto-server-discovery-01 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO S. Kiesel 3 Internet-Draft University of Stuttgart 4 Intended status: Informational M. Tomsu 5 Expires: September 9, 2010 N. Schwan 6 M. Scharf 7 Alcatel-Lucent Bell Labs 8 March 8, 2010 10 Third-party ALTO server discovery 11 draft-kiesel-alto-3pdisc-02 13 Abstract 15 The goal of Application-Layer Traffic Optimization (ALTO) is to 16 provide guidance to applications, which have to select one or several 17 hosts from a set of candidates that are able to provide a desired 18 resource. 20 This document describes why a third-party ALTO server discovery 21 mechanism is required for an important class of applications, namely 22 tracker-based P2P applications. Several solution approaches are 23 classified and evaluated. The conclusion is that further work is 24 required to standardize a protocol and procedures that follow one 25 specific approach. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on September 9, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. The need for third-party ALTO queries . . . . . . . . . . 4 70 2.2. The need for third-party ALTO server discovery . . . . . . 6 71 3. Peer-to-peer application scenario . . . . . . . . . . . . . . 8 72 4. Classification of solution approaches . . . . . . . . . . . . 10 73 4.1. Solutions that do not require an update of the 74 application protocol . . . . . . . . . . . . . . . . . . . 10 75 4.2. Solutions that do require an update of the application 76 protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 5.1. Approach #1 . . . . . . . . . . . . . . . . . . . . . . . 16 79 5.2. Approach #2 . . . . . . . . . . . . . . . . . . . . . . . 16 80 5.3. Approach #3 . . . . . . . . . . . . . . . . . . . . . . . 16 81 5.4. Approach #4 . . . . . . . . . . . . . . . . . . . . . . . 17 82 5.5. Approach #5 . . . . . . . . . . . . . . . . . . . . . . . 17 83 5.6. Approach #6 . . . . . . . . . . . . . . . . . . . . . . . 17 84 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 91 1. Introduction 93 The goal of Application-Layer Traffic Optimization (ALTO) is to 94 provide guidance to applications, which have to select one or several 95 hosts from a set of candidates, that are able to provide a desired 96 resource. ALTO is realized by a client-server protocol. ALTO 97 clients send queries to ALTO servers, in order to solicit guidance. 98 The ALTO client can be embedded in the resource consumer, which will 99 eventually access the desired resource. As an alternative, the ALTO 100 client can be embedded in a resource directory, which assists 101 resource consumers in finding appropriate resource providers. In 102 some specific peer-to-peer application protocols these resource 103 directories are called "trackers". ALTO queries, which are issued by 104 a resource directory on behalf of a resource consumer, will be 105 referred to as third-party ALTO queries. 107 The challenge for third-party ALTO queries is that they have to be 108 answered by the "right" ALTO server, i.e., the ALTO server which has 109 the knowledge to give guidance to the resource consumer on behalf of 110 which the query is sent. 112 This document uses the terminology introduced in [RFC5693] and it 113 investigates solution approaches that fulfill the requirements for 114 ALTO server discovery documented in [I-D.ietf-alto-reqs]. 116 Comments and discussions about this document should be directed to 117 the ALTO working group: alto@ietf.org. 119 2. Problem statement 121 2.1. The need for third-party ALTO queries 123 The scope of this document is the interaction of peer-to-peer 124 applications that use a centralized resource directory ("tracker"), 125 with the ALTO service. In this scenario, the resource consumer 126 ("peer") asks the resource directory for a list of candidate resource 127 providers, which can provide the desired resource. Usually, only a 128 subset of all resource providers known to the resource directory will 129 eventually be contacted by the resource consumer for accessing the 130 resource. The purpose of ALTO is giving guidance on this peer 131 selection, which is supposed to yield better-than-random results. 133 Several ALTO client protocol proposals exist (e.g., 134 [I-D.ietf-alto-protocol], [I-D.kiesel-alto-h12]), which specify how 135 an ALTO client can query an ALTO server for guiding information and 136 receive the corresponding replies. However, in the considered 137 scenario of a tracker-based P2P application, there are two 138 fundamentally different possibilities where to place the ALTO client: 140 1. ALTO client in the resource consumer ("peer") 142 2. ALTO client in the resource directory ("tracker") 144 In the following, both scenarios are compared in order to explain the 145 need for third-party ALTO queries. 147 In the first scenario (see Figure 1), the resource consumer queries 148 the resource directory for the desired resource (F1). The resource 149 directory returns a list of potential resource providers without 150 considering ALTO (F2). It is then the duty of the resource consumer 151 to invoke ALTO (F3/F4), in order to solicit guidance regarding this 152 list. 154 In the second scenario (see Figure 2), the resource directory has an 155 embedded ALTO client, which we will refer to as RDAC in this 156 document. After receiving a query for a given resource (F1) the 157 resource directory invokes the RDAC to evaluate all resource 158 providers it knows (F2/F3). Then it returns a, possibly shortened, 159 list containing the "best" resource providers to the resource 160 consumer (F4). 162 Peer w. ALTO cli. Tracker ALTO Server 163 --------+-------- --------+-------- --------+-------- 164 | F1 Tracker query | | 165 |======================>| | 166 | F2 Tracker reply | | 167 |<======================| | 168 | F3 ALTO client protocol query | 169 |---------------------------------------------->| 170 | F4 ALTO client protocol reply | 171 |<----------------------------------------------| 172 | | | 174 ==== Application protocol (i.e., tracker-based P2P app protocol) 175 ---- ALTO client protocol 177 Figure 1: Basic message sequence chart for resource consumer- 178 initiated ALTO query 180 Peer Tracker w. RDAC ALTO Server 181 --------+-------- --------+-------- --------+-------- 182 | F1 Tracker query | | 183 |======================>| | 184 | | F2 ALTO cli. p. query | 185 | |---------------------->| 186 | | F3 ALTO cli. p. reply | 187 | |<----------------------| 188 | F4 Tracker reply | | 189 |<======================| | 190 | | | 192 ==== Application protocol (i.e., tracker-based P2P app protocol) 193 ---- ALTO client protocol 195 Figure 2: Basic message sequence chart for third-party ALTO query 197 Note: the message sequences depicted in Figure 1 and Figure 2 may 198 occur both in the target-aware and the target-independent query mode 199 (c.f. [I-D.ietf-alto-reqs]). In the target-independent query mode 200 no message exchange with the ALTO server might be needed after the 201 tracker query, because the candidate resource providers could be 202 evaluated using a locally cached "map", which has been retrieved from 203 the ALTO server some time ago. 205 The problem with the first approach is, that while the resource 206 directory might know thousands of peers taking part in a swarm, the 207 list returned to the resource consumer is usually shortened for 208 efficiency reasons. Therefore, the "best" (in the sense of ALTO) 209 potential resource providers might not be contained in that list 210 anymore, even before ALTO can consider them. 212 For example, consider a swarm with 10,000 peers known to the tracker. 213 A new peer wants to join the swarm and therefore asks the tracker for 214 a list of peers. For simplicity, we assume that 100 peers would be 215 desirable neighbors for the new peer (in the sense of better-than- 216 random peer selection) while the other 9,900 are less favorable. 217 Assume that the tracker randomly selects 100 peers out of the 10,000 218 known peers and returns them to the new peer. With a probability of 219 approx. 36% this list does not contain a single favorable peer, and 220 with 99% probability there are only four or less of the favorable 221 peers on the list. Processing this list with the guiding ALTO 222 information will ensure that the few favorable peers are ranked to 223 the top of the list; however, the benefit is rather limited as the 224 number of favorable peers in the list is just too small. Much better 225 traffic optimization could be achieved if the tracker would evaluate 226 all 10,000 peers using ALTO, and return a list of 100 peers 227 afterwards. This list would then include a significantly higher 228 fraction of favorable peers. (Note, that if the tracker returned 229 favorable peers only, there would be a risk that the swarm might 230 disconnect and split into several partitions. However, finding the 231 right mix of ALTO-biased and random peer selection is out of the 232 scope of this document.) 234 Therefore, from an overall optimization perspective, the second 235 scenario with the ALTO client embedded in the resource directory is 236 advantageous, because it is ensured that the addresses of the "best" 237 resource providers are actually delivered to the resource consumer. 239 2.2. The need for third-party ALTO server discovery 241 The previous section has shown why it is advantageous that entities 242 such as resource directories can perform ALTO queries on behalf of 243 resource consumers. We will refer to this kind of ALTO query as 244 "third-party ALTO query". ALTO queries are sent to ALTO servers, 245 which have knowledge of network topology and other information on 246 which the ALTO guidance is based. 248 The challenge for third-party ALTO queries is that they have to be 249 answered by the "right" ALTO server, i.e., the ALTO server which has 250 the knowledge to give guidance to the resource consumer on behalf of 251 which the query is sent. 253 One potential deployment scenario for ALTO is to establish a group of 254 centralized ALTO servers which have complete knowledge and therefore 255 can evaluate any pair of resource consumers and providers, 256 respectively. Directing a third-party ALTO query to one of these 257 servers would be a rather simple task. 259 However, it is likely that there will be deployment scenarios with 260 many ALTO servers, each having only partial knowledge and therefore 261 being able to give guidance regarding only a defined group of 262 resource consumers (e.g., those in its topological vicinity, or those 263 connected to the same network operator). The reasons for 264 partitioning the overall knowledge include scalability and separate 265 administrative responsibilities. For the remainder of this document, 266 we assume that the second scenario has to be supported. The first 267 scenario can be seen as special case of it, i.e., a solution that 268 supports the second scenario will support the first scenario as well. 269 We will identify and assess several approaches for finding the 270 "right" ALTO server, which has the knowledge to give guidance to the 271 resource consumer on behalf of which a third-party ALTO query is to 272 be sent. 274 3. Peer-to-peer application scenario 276 For illustration purposes the following chapters provide several 277 examples, which all refer to the scenario presented in Figure 3. 278 However, the evaluations and conclusions presented in this document 279 do not only consider this scenario, but they are much more general. 281 +------+ +---------+ 282 | ALTO |---+---| Tracker | 283 | Srv3 | | +---------+ 284 +------+ | 285 |RTR| ISP 3 286 | 287 **** | *********** 288 *** ********************** ******* 289 * Internet Backbone Networks * 290 *************** ****************** 291 | ****** ** | 292 |RTR| ISP 1 ****** |RTR| ISP 2 293 | | +------+ 294 +-------+ | +------+ +--------| ALTO | 295 |Peer 1a|----+---| ALTO | | | Srv2 | 296 +-------+ | | Srv1 | |NAT| +------+ 297 | +------+ | 298 +-------+ | +-------+ | +---------+ 299 |Peer 1b|----+ |Peer 2a|----+------|ConfigSrv| 300 +-------+ | +-------+ | +---------+ 301 |RTR| | 302 +-------+ | +-------+ | +-------+ 303 |Peer 1c|----+ |Peer 2b|----+-|RTR|--|Peer 2c| 304 +-------+ +-------+ +-------+ 306 Figure 3: ALTO scenario 308 Figure 3 shows three networks with connected end hosts, which are 309 operated by different Internet Service Provides, identified as ISP1, 310 ISP2, and ISP3, respectively. These networks are interconnected by 311 Internet backbone networks. 313 ISP1's network connects to (amongst others) three hosts that run the 314 peers of a P2P application, identified as peers 1a, 1b, and 1c, 315 respectively. Peers 1a and 1b are in topological vicinity, while 1c 316 is more distant from them, because of the additional router (RTR) in 317 between. ISP1 operates an ALTO server, identified as ALTO Srv1, 318 which can give guidance to resource consumers in ISP1's network, 319 i.e., to peers 1a, 1b, and 1c. 321 ISP2's network has a very similar structure as described above, and 322 it contains peers 2a, 2b, and 2c, as well as ALTO Srv2. The main 323 difference to ISP1's network is that ISP2 uses a carrier grade NAT 324 device, in order to masquerade peers 2a, 2b, and 2c "behind" one 325 single "external" (globally unique) IPv4 address. ALTO server 2 is 326 assumed to have a globally unique IPv4 address, i.e., it can be 327 queried from other hosts in the Internet without any special NAT 328 traversal mechanisms. 330 ISP3's network contains a resource directory ("tracker") for a 331 tracker-based P2P application. ISP3 operates ALTO Srv3, which is 332 populated with information that could be used for giving guidance to 333 resource consumers in ISP3's network. 335 We assume that the tracker already knows that peers 1b, 1c, 2b, and 336 2c are taking part in a specific P2P overlay. If peer 1a wishes to 337 join the overlay, it sends an application protocol specific message 338 to the tracker, asking for other peer's addresses. Because of the 339 reasons outlined in Section 2.1 the tracker should ask ALTO for 340 guidance prior to replying. More specifically, it should query ALTO 341 server 1, because this ALTO server can give guidance to peer 1a. 342 Analogical to that, if peer 2a sends a query to the tracker, the 343 tracker needs to ask ALTO server 2 for guidance. The procedures for 344 identifying this ALTO server and conveying the guiding information to 345 the tracker are the scope of this document. 347 4. Classification of solution approaches 349 There are several approaches for directing a third-party ALTO query 350 from the RDAC to the "right" ALTO server. The selection of the 351 "right" ALTO server needs to consider the resource consumer on behalf 352 of which the query will be performed. The set of available options 353 therefore depends on the available information about the resource 354 consumer, 356 The primary criterion in the following classification is whether ALTO 357 must work together with all existing (P2P) application protocols, or 358 whether we can assume that these protocols can be augmented with new 359 ALTO-specific information fields. 361 4.1. Solutions that do not require an update of the application 362 protocol 364 If we do not want to make specific assumptions on the (P2P) 365 application protocol, we cannot assume that there are any other peer 366 identifiers apart from IP addresses. Therefore, we assume that the 367 only information identifying the resource consumer is the source IP 368 address of messages sent from the resource consumer to the resource 369 directory. This address may be the (public) IP address of the 370 resource consumer, or it may be the external address of the last NAT 371 on the path between resource consumer and resource directory. 373 The RDAC that wants to perform the third-party ALTO query has two 374 options: 376 o Approach #1: The RDAC invokes a discovery mechanism external to 377 the ALTO client protocol, in order to map from the resource 378 consumer's IP address to the "right" ALTO server. The ALTO query 379 will then be sent there directly (see Figure 4). 381 o Approach #2: Independent of the resource consumer's identity, the 382 RDAC uses the ALTO client protocol to send the ALTO query to one 383 preconfigured ALTO server. The resource consumer's IP address is 384 included in the query message. Based on this IP address and using 385 mechanisms of the ALTO client protocol the first ALTO server 386 forwards (see Figure 5) or redirects (see Figure 6) the query to 387 the "right" ALTO server. This implies that ALTO servers must know 388 each other, based on some discovery mechanism or manual 389 configuration. 391 Peer 1a Tracker ALTO Srv1 DNS 392 ----+---- ----+---- ----+---- ----+---- 393 | | | | 394 | F1 Tracker Q | | | 395 |==============>| F2 ALTO disc. Q (peer1a) | 396 | |******************************>| 397 | | F3 ALTO disc. R: ALTO Srv1 | 398 | |<******************************| 399 | | F4 ALTO cp Q | | 400 | |-------------->| | 401 | | F5 ALTO cp R | | 402 | F6 Tracker R |<--------------| | 403 |<==============| | | 404 | | | | 406 ==== Application protocol (i.e., tracker-based P2P app protocol) 407 ---- ALTO client protocol 408 **** ALTO discovery protocol (e.g., based on DNS queries) 410 Figure 4: Message sequence chart for Approach 1 412 Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3 413 ----+---- ----+---- ----+---- ----+---- ----+---- 414 | | | F1/2 HELLO | | 415 | | |<###########>| F3/4 HELLO | 416 | | | F5/6 HELLO |<###########>| 417 | | |<#########################>| 418 | F7 Tracker Q | | | | 419 |==============>| | | | 420 | | F8 ALTO cp Q | | | 421 | |------------------------------------------>| 422 | | | F9 ALTO cp Q | 423 | | |<--------------------------| 424 | | | F10 ALTO cp R | 425 | | |-------------------------->| 426 | | F11 ALTO cp R | | | 427 | F12 Tracker R |<------------------------------------------| 428 |<==============| | | | 429 | | | | | 431 ==== Application protocol (i.e., tracker-based P2P app protocol) 432 ---- ALTO client protocol 433 #### Inter-ALTO server protocol 435 Figure 5: Message sequence chart for Approach 2 (query forwarding) 436 Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3 437 ----+---- ----+---- ----+---- ----+---- ----+---- 438 | | | F1/2 HELLO | | 439 | | |<###########>| F3/4 HELLO | 440 | | | F5/6 HELLO |<###########>| 441 | | |<#########################>| 442 | F7 Tracker Q | | | | 443 |==============>| | | | 444 | | F8 ALTO cp Q | | | 445 | |------------------------------------------>| 446 | | F9 ALTO cp redirect | | 447 | |<------------------------------------------| 448 | | F10 ALTO cp Q | | | 449 | |-------------->| | | 450 | | F11 ALTO cp R | | | 451 | F12 Tracker R |<--------------| | | 452 |<==============| | | | 453 | | | | | 455 ==== Application protocol (i.e., tracker-based P2P app protocol) 456 ---- ALTO client protocol 457 #### Inter-ALTO server protocol 459 Figure 6: Message sequence chart for Approach 2 (query redirection) 461 4.2. Solutions that do require an update of the application protocol 463 If we assume that applications can be upgraded in order to support 464 ALTO, the resource consumer can provide additional information to the 465 RDAC in order to assist the process of ALTO server discovery. 467 o Approach #3: Using the extended application protocol, the resource 468 consumer sends an additional peer-ID, which can be understood by 469 ALTO, to the resource directory. This peer-ID could be used to 470 uniquely identify resource consumers and providers located behind 471 NATs. The RDAC uses this peer-ID in addition to or instead of the 472 resource consumer's IP address (see Figure 7). In all other 473 aspects this approach is identical to approach #1. 475 o Approach #4: This approach is identical to approach #2, except 476 that the peer-ID is used instead of the IP address, as described 477 in approach #3. 479 o Approach #5: The resource consumer discovers its ALTO server on 480 its own (i.e., not a third-party discovery). Using the extended 481 application protocol it sends the ALTO server's address to the 482 RDAC. The RDAC can use it for sending third-party ALTO queries 483 there. 485 o Approach #6: The resource consumer retrieves guiding information 486 on its own, e.g., by discovering and querying an ALTO server or by 487 doing measurements. Using the extended application protocol it 488 sends this information to the tracker, which can perform peer 489 selection based on it. 491 Peer 2a ConfigSrv Tracker ALTO Srv2 DNS 492 ----+---- ----+---- ----+---- ----+---- ----+--- 493 | F1 Config Q | | | | 494 |;;;;;;;;;;;;;;>| | | | 495 | | | | | 496 | F2 Config R | | | | 497 | + LocalID LID | | | | 498 |<;;;;;;;;;;;;;;| | | | 499 | | | | | 500 | F3 Tracker Q (LID) | | | 501 |===========================>| F4 ALTO disc. Q (ext.IP+LID) | 502 | | |******************************>| 503 | | | F5 ALTO disc. R: ALTO Srv2 | 504 | | |<******************************| 505 | | | F6 ALTO cp Q | | 506 | | |-------------->| | 507 | | | F7 ALTO cp R | | 508 | F8 Tracker R | |<--------------| | 509 |<===========================| | | 510 | | | | | 512 ;;;; Configuration protocol (e.g., DHCP) 513 ==== Application protocol (i.e., tracker-based P2P app protocol) 514 ---- ALTO client protocol 515 **** ALTO discovery protocol (e.g., based on DNS queries) 517 Figure 7: Message sequence chart for Approach 3 519 Peer 2a ConfigSrv Tracker ALTO Srv2 520 ----+---- ----+---- ----+---- ----+---- 521 | F1 Config Q | | | 522 |;;;;;;;;;;;;;;>| | | 523 | | | | 524 | F2 Config R | | | 525 | + Addr. of ALTO Srv2 | | 526 |<;;;;;;;;;;;;;;| | | 527 | | | | 528 | F3 Tracker Q (Addr. of ALTO Srv2) | 529 |==============================>| | 530 | | | F4 ALTO cp Q | 531 | | |-------------->| 532 | | | F5 ALTO cp R | 533 | F6 Tracker R | |<--------------| 534 |<==============================| | 535 | | | | 537 ;;;; Configuration protocol (e.g., DHCP) 538 ==== Application protocol (i.e., tracker-based P2P app protocol) 539 ---- ALTO client protocol 541 Figure 8: Message sequence chart for Approach 5 543 Peer 2a ConfigSrv Tracker ALTO Srv2 544 ----+---- ----+---- ----+---- ----+---- 545 | F1 Config Q | | | 546 |;;;;;;;;;;;;;;>| | | 547 | | | | 548 | F2 Config R | | | 549 | + Addr. of ALTO Srv2 | | 550 |<;;;;;;;;;;;;;;| | | 551 | | | | 552 | F3 ALTO cp Q | | | 553 |---------------------------------------------->| 554 | F4 ALTO cp R | | | 555 |<----------------------------------------------| 556 optional: perform | | | 557 measurements | | | 558 | | | | 559 | F5 Tracker Q (Info from ALTO reply + meas'mt.)| 560 |==============================>| | 561 | F6 Tracker R | | | 562 |<==============================| | 563 | | | | 565 ;;;; Configuration protocol (e.g., DHCP) 566 ==== Application protocol (i.e., tracker-based P2P app protocol) 567 ---- ALTO client protocol 569 Figure 9: Message sequence chart for Approach 6 571 5. Discussion 573 This section assesses and compares the different approaches 574 introduced above, regarding trust, scalability, integration into 575 existing ISP infrastructure and management processes, modification of 576 existing applications, and ongoing ALTO architecture specification 577 works. 579 5.1. Approach #1 581 The existence of a mechanism according to approach #1 is assumed by 582 [I-D.ietf-alto-protocol]. 584 This approach does not require any changes of existing (P2P) 585 application protocols. However, the RDAC needs to implement an 586 additional protocol for performing third-party ALTO server discovery. 588 One possible way of implementing this approach would be based on DNS, 589 providing a mapping from the resource consumer's IP address to the IP 590 address of the corresponding "right" ALTO server. DNS is proven to 591 be scalable and has well-understood mechanisms for delegating 592 authority. Network operators are used to DNS management. 594 This approach does not support intra-domain traffic optimization for 595 large domains behind a NAT. 597 5.2. Approach #2 599 This approach does not require any changes of existing (P2P) 600 application protocols. 602 Furthermore, the RDAC does not need to implement an additional 603 protocol besides the ALTO client protocol. However, this approach 604 relocates the discovery problem from the RDAC to the first ALTO 605 server. 607 This first ALTO server, when preconfigured in the RDAC of a large 608 resource directory, would raise serious concerns about scalability 609 and trust/security issues. 611 This approach does not support intra-domain traffic optimization for 612 large domains behind a NAT. 614 5.3. Approach #3 616 This approach requires changes to all existing (P2P) application 617 protocols that want to benefit from ALTO. 619 This approach supports intra-domain traffic optimization for large 620 domains behind a NAT. 622 Except for the above mentioned statements, the same results as for 623 approach #1 apply. 625 5.4. Approach #4 627 This approach requires changes to all existing (P2P) application 628 protocols that want to benefit from ALTO. 630 This approach supports intra-domain traffic optimization for large 631 domains behind a NAT. 633 Except for the above mentioned statements, the same results as for 634 approach #2 apply. 636 5.5. Approach #5 638 This approach requires changes to all existing (P2P) application 639 protocols that want to benefit from ALTO. 641 This approach does not need a mechanism for third-party ALTO server 642 discovery, as the ALTO server is discovered by the resource consumer. 643 However, a mechanism for this kind of discovery is needed, see, e.g., 644 [I-D.song-alto-server-discovery]. 646 Unlike approaches #1 .. #4 this approach supports scenarios, in which 647 there is not exactly one "right" ALTO server for any given resource 648 consumer. Instead of sending the address of the ALTO server 649 provisioned by the ISP, the resource consumer can also send the 650 address of another ALTO server of its choice to the RDAC. 652 5.6. Approach #6 654 This approach requires changes to all existing (P2P) application 655 protocols that want to benefit from ALTO. 657 This approach does not need a mechanism for third-party ALTO server 658 discovery, as the ALTO server is discovered by the resource consumer. 659 However, a mechanism for this kind of discovery is needed, see, e.g., 660 [I-D.song-alto-server-discovery]. 662 Unlike approaches #1 .. #4 this approach supports scenarios, in which 663 there is not exactly one "right" ALTO server for any given resource 664 consumer. Instead of querying the ALTO server provisioned by the ISP 665 and forwarding that information to the resource directory, the 666 resource consumer can also query any other ALTO server of its choice. 668 This approach allows the resource consumer to augment the ALTO 669 server's reply with local preferences (e.g., from measurements). It 670 is also possible not to query an ALTO server at all. 672 6. Conclusion 674 This document describes why a third-party ALTO server discovery 675 mechanism is required for an important class of applications, namely 676 tracker-based P2P applications. Several solution approaches are 677 classified and evaluated. Assuming that ALTO should work together 678 with already deployed application protocols, "Approach #1" seems to 679 be most promising. In this approach, the resource directory invokes 680 a discovery mechanism external to the ALTO client protocol, in order 681 to map from the resource consumer's IP address to the "right" ALTO 682 server. 684 The existence of such a mechanism according to "Approach #1" is 685 assumed by [I-D.ietf-alto-protocol]. 687 Further action is required to standardize a protocol and procedures 688 according to "Approach #1". 690 7. IANA Considerations 692 This document does not mandate any immediate IANA actions. However, 693 such IANA considerations may arise from future ALTO discovery 694 specification documents which try to meet the requirements given 695 here. 697 8. Security Considerations 699 This early version of this memo does not yet have any security 700 considerations, but they will be added in future revision. 702 9. References 704 [I-D.ietf-alto-protocol] 705 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 706 draft-ietf-alto-protocol-02 (work in progress), 707 March 2010. 709 [I-D.ietf-alto-reqs] 710 Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. 711 Yang, "Application-Layer Traffic Optimization (ALTO) 712 Requirements", draft-ietf-alto-reqs-03 (work in progress), 713 February 2010. 715 [I-D.kiesel-alto-h12] 716 Kiesel, S. and M. Stiemerling, "ALTO H12", 717 draft-kiesel-alto-h12-01 (work in progress), March 2010. 719 [I-D.song-alto-server-discovery] 720 Song, H., Tomsu, M., Garcia, G., Wang, Y., and V. Pascual, 721 "ALTO Service Discovery", 722 draft-song-alto-server-discovery-01 (work in progress), 723 July 2009. 725 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 726 Optimization (ALTO) Problem Statement", RFC 5693, 727 October 2009. 729 Appendix A. Acknowledgments 731 The authors would like to thank Haibin Song, Richard Alimi, and Roni 732 Even for fruitful discussions during the 75th IETF meeting. 734 Marco Tomsu and Nico Schwan are partially supported by the ENVISION 735 project (http://www.envision-project.org), a research project 736 supported by the European Commission under its 7th Framework Program 737 (contract no. 248565). The views and conclusions contained herein 738 are those of the authors and should not be interpreted as necessarily 739 representing the official policies or endorsements, either expressed 740 or implied, of the ENVISION project or the European Commission. 742 Michael Scharf is supported by the German-Lab project 743 (http://www.german-lab.de) funded by the German Federal Ministry of 744 Education and Research (BMBF). 746 Authors' Addresses 748 Sebastian Kiesel 749 University of Stuttgart Computing Center 750 Allmandring 30 751 Stuttgart 70550 752 Germany 754 Email: ietf-alto@skiesel.de 755 URI: http://www.rus.uni-stuttgart.de/nks/ 757 Marco Tomsu 758 Alcatel-Lucent Bell Labs 759 Lorenzstrasse 10 760 Stuttgart 70435 761 Germany 763 Email: marco.tomsu@alcatel-lucent.com 764 URI: www.alcatel-lucent.com/bell-labs 766 Nico Schwan 767 Alcatel-Lucent Bell Labs 768 Lorenzstrasse 10 769 Stuttgart 70435 770 Germany 772 Email: nico.schwan@alcatel-lucent.com 773 URI: www.alcatel-lucent.com/bell-labs 775 Michael Scharf 776 Alcatel-Lucent Bell Labs 777 Lorenzstrasse 10 778 Stuttgart 70435 779 Germany 781 Email: michael.scharf@alcatel-lucent.com 782 URI: www.alcatel-lucent.com/bell-labs