idnits 2.17.1 draft-stiemerling-alto-deployments-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 22 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 160 has weird spacing: '...logical ser...' == Line 188 has weird spacing: '...logical ser...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 25, 2011) is 4811 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 ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 983, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-06 == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-07 == Outdated reference: A later version (-09) exists of draft-kamei-p2p-experiments-japan-04 == Outdated reference: A later version (-05) exists of draft-kiesel-alto-3pdisc-04 == Outdated reference: A later version (-03) exists of draft-penno-alto-cdn-02 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO M. Stiemerling 3 Internet-Draft NEC Europe Ltd. 4 Intended status: Informational S. Kiesel 5 Expires: July 29, 2011 University of Stuttgart 6 January 25, 2011 8 ALTO Deployment Considerations 9 draft-stiemerling-alto-deployments-06 11 Abstract 13 Many Internet applications are used to access resources, such as 14 pieces of information or server processes, which are available in 15 several equivalent replicas on different hosts. This includes, but 16 is not limited to, peer-to-peer file sharing applications. The goal 17 of Application-Layer Traffic Optimization (ALTO) is to provide 18 guidance to these applications, which have to select one or several 19 hosts from a set of candidates, that are able to provide a desired 20 resource. The protocol is under specification in the ALTO working 21 group. This memo discusses deployment related issues of ALTO for 22 peer-to-peer and CDNs, some preliminary security considerations, and 23 also initial guidance for application designers using ALTO. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 29, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. General Placement of ALTO . . . . . . . . . . . . . . . . 4 62 2.2. Provided Guidance . . . . . . . . . . . . . . . . . . . . 6 63 2.2.1. Keeping Traffic Local in Network . . . . . . . . . . . 6 64 2.2.2. Off-Loading Traffic from Network . . . . . . . . . . . 7 65 2.2.3. Intra-Network Localization/Bottleneck Off-Loading . . 8 66 3. Using ALTO for Peer-to-Peer . . . . . . . . . . . . . . . . . 11 67 3.1. Using ALTO for Tracker-based Peer-to-Peer Applications . . 13 68 3.2. Expectations of ALTO . . . . . . . . . . . . . . . . . . . 15 69 4. Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . . 16 70 5. Cascading ALTO Servers . . . . . . . . . . . . . . . . . . . . 17 71 6. Known Limitations of ALTO . . . . . . . . . . . . . . . . . . 19 72 6.1. Limitations of Map-based Approaches . . . . . . . . . . . 19 73 6.2. Limitiations of Non-Map-based Approaches . . . . . . . . . 20 74 6.3. General Challenges . . . . . . . . . . . . . . . . . . . . 20 75 7. API between ALTO Client and Application . . . . . . . . . . . 22 76 8. Extensions to the ALTO Protocol . . . . . . . . . . . . . . . 23 77 8.1. Host Group Descriptors . . . . . . . . . . . . . . . . . . 23 78 8.2. Rating Criteria . . . . . . . . . . . . . . . . . . . . . 23 79 8.2.1. Distance-related Rating Criteria . . . . . . . . . . . 23 80 8.2.2. Charging-related Rating Criteria . . . . . . . . . . . 24 81 8.2.3. Performance-related Rating Criteria . . . . . . . . . 24 82 8.2.4. Inappropriate Rating Criteria . . . . . . . . . . . . 25 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 84 9.1. Information Leakage from the ALTO Server . . . . . . . . . 26 85 9.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 26 86 9.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 27 87 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 91 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 31 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 94 1. Introduction 96 Many Internet applications are used to access resources, such as 97 pieces of information or server processes, which are available in 98 several equivalent replicas on different hosts. This includes, but 99 is not limited to, peer-to-peer file sharing applications and Content 100 Delivery Networks (CDNs). The goal of Application-Layer Traffic 101 Optimization (ALTO) is to provide guidance to applications, which 102 have to select one or several hosts from a set of candidates, that 103 are able to provide a desired resource. The basic ideas of ALTO are 104 described in the problem space of ALTO is described in [RFC5693] and 105 the set of requirements is discussed in [I-D.ietf-alto-reqs]. 107 However, there are no considerations about what operational issues 108 are to be expected once ALTO will be deployed. This includes, but is 109 not limited to, location of the ALTO server, imposed load to the ALTO 110 server, or from whom the queries are performed. 112 Comments and discussions about this memo should be directed to the 113 ALTO working group: alto@ietf.org. 115 2. Overview 117 The ALTO protocol is a client/server protocol, operating between a 118 number of ALTO clients and an ALTO server, as sketched in Figure 1. 119 The ALTO working groups defines the ALTO protocol 120 [I-D.ietf-alto-protocol]. 122 +----------+ 123 | ALTO | 124 | Server | 125 +----------+ 126 ^ 127 _.-----|------. 128 ,-'' | `--. 129 ,' | `. 130 ( Network | ) 131 `. | ,' 132 `--. | _.-' 133 `------|-----'' 134 v 135 +----------+ +----------+ +----------+ 136 | ALTO | | ALTO |...| ALTO | 137 | Client | | Client | | Client | 138 +----------+ +----------+ +----------+ 140 Figure 1: Network Overview of ALTO Protocol 142 2.1. General Placement of ALTO 144 The ALTO server and ALTO clients can be situated at various entities 145 in a network deployment. The first differentiation is whether the 146 ALTO client is located on the actual host that runs the application, 147 as shown in Figure 2, (e.g., peer-to-peer filesharing application) or 148 if the ALTO client is located on resource directory, as shown in 149 Figure 3 (e.g., a tracker in peer-to-peer filesharing). 151 +-----+ 152 =====| |** 153 ==== +-----+ * 154 ==== * * 155 ==== * * 156 +-----+ +------+===== +-----+ * 157 | |.....| |======================| | * 158 +-----+ +------+===== +-----+ * 159 Source of ALTO ==== * * 160 topological service ==== * * 161 information ==== +-----+ * 162 =====| |** 163 +-----+ 164 Legend: 165 === ALTO client protocol 166 *** Application protocol 167 ... Provisioning protocol 169 Figure 2: Overview of protocol interaction between ALTO 170 elements,scenario without tracker 172 Figure 2 shows the operational model for applications that do not use 173 a tracker, such as, edonky, or in if the tracker should be the 174 querying party. This use case also holds true for CDNs. The ALTO 175 server can also be queried by CDNs to get a guidance about where the 176 a particular client accessing data in the CDN is exactly located in 177 the ISP's network. 179 +-----+ 180 **| |** 181 ** +-----+ * 182 ** * * 183 ** * * 184 +-----+ +------+ +-----+** +-----+ * 185 | |.....| |=====| |**********| | * 186 +-----+ +------+ +-----+** +-----+ * 187 Source of ALTO Resource ** * * 188 topological service directory ** * * 189 information ("tracker") ** +-----+ * 190 **| |** 191 +-----+ 192 Peers 193 Legend: 194 === ALTO client protocol 195 *** Application protocol 196 ... Provisioning protocol 198 Figure 3: Overview of protocol interaction between ALTO elements, 199 scenario with tracker 201 However, Figure 3 does not denote where the ALTO elements are 202 actually located, i.e., if the tracker and the ALTO server are in the 203 same ISP's domain, or if the tracker and the ALTO server are managed/ 204 owned/located in different domains. The latter is the typical use 205 case, e.g., taking Pirate Bay as example that serves Bittorrent peers 206 world-wide. 208 2.2. Provided Guidance 210 ALTO gives guidance to applications on what IP addresses or IP 211 prefixes, and such which hosts are to be preferred according to the 212 operator of the ALTO server. The general assumption of the ALTO WG 213 is that a network operator would always express to prefer hosts in 214 its own network while hosts located outside its own network are to be 215 avoided (are undesired to be considered by the applications). This 216 might be applicable in some cases but may not be applicable in the 217 general case. The ALTO protocol gives only the means to let the ALTO 218 server operator to express is preference, whatever this preference 219 is. This section explores this space. 221 2.2.1. Keeping Traffic Local in Network 223 ALTO guidance can be used to let applications prefer other peers 224 within the same network operator's network instead of randomly 225 connecting to other peers which are located in another operator's 226 network. Figure 4 shows such a scenario where peers prefer peers in 227 the same network (e.g., Peer 1 and Peer 2 in ISP1 and Peer 3 and Peer 228 4 in ISP2). 230 ,-------. +-----------+ 231 ,---. ,-' `-. | Peer 1 | 232 ,-' `-. / ISP 1 ########|ALTO Client| 233 / \ / # \ +-----------+ 234 / ISP X \ | # | +-----------+ 235 / \ \ ########| Peer 2 | 236 ; +----------------------------|ALTO Client| 237 | | | `-. ,-' +-----------+ 238 | | | `-------' 239 | | | ,-------. +-----------+ 240 : | ; ,-' `########| Peer 3 | 241 \ | / / ISP 2 # \ |ALTO Client| 242 \ | / / # \ +-----------+ 243 \ +---------+ # | +-----------+ 244 `-. ,-' \ | ########| Peer 4 | 245 `---' \ +------------------|ALTO Client| 246 `-. ,-' +-----------+ 247 `-------' 249 Legend: 250 ### preferred "connections" 251 --- non-preferred "connections" 253 Figure 4: ALTO Traffic Network Localization 255 TBD: Describes limits of this approach (e.g., traffic localization 256 guidance is of less use if the peers cannot upload); describe how 257 maps would look like. 259 2.2.2. Off-Loading Traffic from Network 261 Another scenario where the use of ALTO can be beneficial is in mobile 262 broadband networks, e.g., CDMA200 or UMTS, but where the network 263 operator may have the desire to guide peers in its own network to use 264 peers in remote networks. One reason can be that the wireless 265 network is not made for the load cause by, e.g., peer-to-peer 266 applications, and the operator has the need that peers fetch their 267 data from remote peers in other parts of the Internet. 269 ,-------. +-----------+ 270 ,---. ,-' `-. | Peer 1 | 271 ,-' `-. / ISP 1 +-------|ALTO Client| 272 / \ / | \ +-----------+ 273 / ISP X \ | | | +-----------+ 274 / \ \ +-------| Peer 2 | 275 ; #-###########################|ALTO Client| 276 | # | `-. ,-' +-----------+ 277 | # | `-------' 278 | # | ,-------. +-----------+ 279 : # ; ,-' `+-------| Peer 3 | 280 \ # / / ISP 2 | \ |ALTO Client| 281 \ # / / | \ +-----------+ 282 \ ########### | | +-----------+ 283 `-. ,-' \ # +-------| Peer 4 | 284 `---' \ ###################|ALTO Client| 285 `-. ,-' +-----------+ 286 `-------' 288 Legend: 289 === preferred "connections" 290 --- non-preferred "connections" 292 Figure 5: ALTO Traffic Network De-Localization 294 Figure 5 shows the result of such a guidance process where Peer 2 295 prefers a connection with Peer4 instead of Peer 1, as shown in 296 Figure 4. 298 TBD: Limits of this approach in general and with respect to p2p. 299 describe how maps would look like. 301 2.2.3. Intra-Network Localization/Bottleneck Off-Loading 303 The above sections described the results of the ALTO guidance on an 304 inter-network level. However, ALTO can also be used to guide peers 305 on which internal peers are to be preferred. For instance, to guide 306 Peers on a remote network side to prefer to connect to each other, 307 instead of crossing a bottleneck link, a backhaul link to connect the 308 side to the network core. Figure 6 shows such a scenario where Peer 309 1 and Peer 2 are located in Net 2 of ISP1 and connect via a low 310 capacity link to the core (Net 1) of the same ISP1. Peer1 and Peer 2 311 would both exchange their data with remote peers, probably clogging 312 the bottleneck link. 314 ,-------. +-----------+ 315 ,---. ,-' `-. | Peer 1 | 316 ,-' `-. / ISP 1 #########|ALTO Client| 317 / \ / Net 2 # \ +-----------+ 318 / ISP 1 \ | ######### | +-----------+ 319 / Net 1 \ \ # / | Peer 2 | 320 ; ###; \ # ##########|ALTO Client| 321 | X~~~~~~~~~~~~X#######,-' +-----------+ 322 | ### | ^ `-------' 323 | | | 324 : ; | 325 \ / Bottleneck 326 \ / 327 \ / 328 `-. ,-' 329 `---' 330 Legend: 331 ### peer "connections" 332 ~~~ bottleneck link 334 Figure 6: Without Intra-Network ALTO Traffic Localization 336 The operator can guide the peers in such a situation to try first 337 local peers in the same network islands, avoiding or at least 338 lowering the effect on the bottleneck link, as shown in Figure 7. 340 ,-------. +-----------+ 341 ,---. ,-' `-. | Peer 1 | 342 ,-' `-. / ISP 1 #########|ALTO Client| 343 / \ / Net 2 # \ +-----------+ 344 / ISP 1 \ | # | +-----------+ 345 / Net 1 \ \ #########| Peer 2 | 346 ; ; \ ##########|ALTO Client| 347 | #~~~~~~~~~~~########,-' +-----------+ 348 | ### | ^ `-------' 349 | | | 350 : ; | 351 \ / Bottleneck 352 \ / 353 \ / 354 `-. ,-' 355 `---' 356 Legend: 357 ### peer "connections" 358 ~~~ bottleneck link 360 Figure 7: With Intra-Network ALTO Traffic Localization 362 TBD: describe how maps would look like. 364 3. Using ALTO for Peer-to-Peer 365 ,-------. 366 ,---. ,-' `-. +-----------+ 367 ,-' `-. / ISP 1 \ | Peer 1 |***** 368 / \ / +-------------+ \ | | * 369 / ISP X \ +=====>+ ALTO Server | )+-----------+ * 370 / \ = \ +-------------+ / +-----------+ * 371 ; +-----------+ : = \ / | Peer 2 | * 372 | | Tracker |<====+ `-. ,-' | |***** 373 | |ALTO Client|<====+ `-------' +-----------+ ** 374 | +-----------+ | = ,-------. ** 375 : * ; = ,-' `-. +-----------+ ** 376 \ * / = / ISP 2 \ | Peer 3 | ** 377 \ * / = / +-------------+ \ | |***** 378 \ * / +=====>| ALTO Server | )+-----------+ *** 379 `-. * ,-' \ +-------------+ / +-----------+ *** 380 `-*-' \ / | Peer 4 |***** 381 * `-. ,-' | | **** 382 * `-------' +-----------+ **** 383 * **** 384 * **** 385 ***********************************************<****** 386 Legend: 387 === ALTO client protocol 388 *** Application protocol 390 Figure 8: Global tracker accessing ALTO server at various ISPs 392 Figure 8 depicts a tracker-based system, where the tracker embeds the 393 ALTO client. The tracker itself is hosted and operated by an entity 394 different than the ISP hosting and operating the ALTO server. 395 Initially, the tracker has to look-up the ALTO server in charge for 396 each peer where it receives a ALTO query for. Therefore, the ALTO 397 server has to discover the handling ALTO server, as described in 398 [I-D.kiesel-alto-3pdisc]. However, the peers do not have any way to 399 query the server themselves. This setting allows to give the peers a 400 better selection of candidate peers for their operation at an initial 401 time, but does not consider peers learned through direct peer-to-peer 402 knowledge exchange, AKA peer exchange in various peer-to-peer 403 protocols. 405 ,-------. +-----------+ 406 ,---. ,-' `-. +==>| Peer 1 |***** 407 ,-' `-. / ISP 1 \ = |ALTO Client| * 408 / \ / +-------------+<=+ +-----------+ * 409 / ISP X \ | + ALTO Server |<=+ +-----------+ * 410 / \ \ +-------------+ /= | Peer 2 | * 411 ; +---------+ : \ / +==>|ALTO Client|***** 412 | | Global | | `-. ,-' +-----------+ ** 413 | | Tracker | | `-------' ** 414 | +---------+ | ,-------. +-----------+ ** 415 : * ; ,-' `-. +==>| Peer 3 | ** 416 \ * / / ISP 2 \ = |ALTO Client|***** 417 \ * / / +-------------+<=+ +-----------+ *** 418 \ * / | | ALTO Server |<=+ +-----------+ *** 419 `-. * ,-' \ +-------------+ /= | Peer 4 |***** 420 `-*-' \ / +==>|ALTO Client| **** 421 * `-. ,-' +-----------+ **** 422 * `-------' **** 423 * **** 424 ***********************************************<**** 425 Legend: 426 === ALTO client protocol 427 *** Application protocol 429 Figure 9: Global Tracker - Local ALTO Servers 431 The scenario in Figure 9 lets the peers directly communicate with 432 their ISP's ALTO server (i.e., ALTO client embedded in the peers), 433 giving thus the peers the most control on which information they 434 query for, as they can integrate information received from trackers 435 and through direct peer-to-peer knowledge exchange. 437 ,-------. +-----------+ 438 ,---. ,-' ISP 1 `-. ***>| Peer 1 | 439 ,-' `-. /+-------------+\ * | | 440 / \ / + Tracker |<** +-----------+ 441 / ISP X \ | +-----===-----+<** +-----------+ 442 / \ \ +-----===-----+ /* | Peer 2 | 443 ; +---------+ : \+ ALTO Server |/ ***>| | 444 | | Global | | +-------------+ +-----------+ 445 | | Tracker | | `-------' 446 | +---------+ | +-----------+ 447 : ^ ; ,-------. | Peer 3 | 448 \ * / ,-' ISP 2 `-. ***>| | 449 \ * / /+-------------+\ * +-----------+ 450 \ * / / + Tracker |<** +-----------+ 451 `-. *,-' | +-----===-----+ | | Peer 4 |<* 452 `---* \ +-----===-----+ / | | * 453 * \+ ALTO Server |/ +-----------+ * 454 * +-------------+ * 455 * `-------' * 456 *********************************************** 457 Legend: 458 === ALTO client protocol 459 *** Application protocol 461 Figure 10: P4P approach with local tracker and local ALTO server 463 There are some attempts to let ISP's to deploy their own trackers, as 464 shown in Figure 10. In this case, the client has no chance to get 465 guidance from the ALTO server, other than talking to the ISP's 466 tracker. However, the peers would have still chance the contact 467 other trackers, deployed by entities other than the peer's ISP. 469 Figure 10 and Figure 8 ostensibly take peers the possibility to 470 directly query the ALTO server, if the communication with the ALTO 471 server is not permitted for any reason. However, considering the 472 plethora of different applications of ALTO, e.g., multiple tracker 473 and non-tracker based P2P systems and or applications searching for 474 relays, it seems to be beneficial for all participants to let the 475 peers directly query the ALTO server. The peers are also the single 476 point having all operational knowledge to decide whether to use the 477 ALTO guidance and how to use the ALTO guidance. This is a preference 478 for the scenario depicted in Figure Figure 9. 480 3.1. Using ALTO for Tracker-based Peer-to-Peer Applications 481 ............................. ............................. 482 : Tracker : : Peer : 483 : ______ : : : 484 : +-______-+ : : k good : 485 : | | +--------+ : P2P App. : +--------+ peers +------+ : 486 : | N | | random | : Protocol : | ALTO- |------>| data | : 487 : | known |====>| pre- |*************>| biased | | ex- | : 488 : | peers, | | selec- | : transmit : | peer |------>| cha- | : 489 : | M good | | tion | : n peer : | select | n-k | nge | : 490 : +-______-+ +--------+ : IDs : +--------+ bad p.+------+ : 491 :...........................: :.....^.....................: 492 | 493 | ALTO 494 | client protocol 495 __|___ 496 +-______-+ 497 | | 498 | ALTO | 499 | server | 500 +-______-+ 502 Figure 11: Tracker-based P2P Application with random peer 503 preselection 505 ............................. ............................. 506 : Tracker : : Peer : 507 : ______ : : : 508 : +-______-+ : : : 509 : | | +--------+ : P2P App. : k good peers & +------+ : 510 : | N | | ALTO- | : Protocol : n-k bad peers | data | : 511 : | known |====>| biased |******************************>| ex- | : 512 : | peers, | | peer | : transmit : | cha- | : 513 : | M good | | select | : n peer : | nge | : 514 : +-______-+ +--------+ : IDs : +------+ : 515 :.....................^.....: :...........................: 516 | 517 | ALTO 518 | client protocol 519 __|___ 520 +-______-+ 521 | | 522 | ALTO | 523 | server | 524 +-______-+ 526 Figure 12: Tracker-based P2P Application with ALTO client in tracker 527 TBD: explain why Figure 12 usually will yield better results wrt. 528 peer selection than Figure 11. 530 3.2. Expectations of ALTO 532 This section hints to some recent experiments conducted with ALTO- 533 like deployments in Internet Service Provider (ISP) network's. NTT 534 performed tests with their HINT server implementation and dummy nodes 535 to gain insight on how an ALTO-like service influence a peer-to-peer 536 systems [I-D.kamei-p2p-experiments-japan]. The results of an early 537 experiment conducted in the Comcast network are documented 538 here[RFC5632] 540 4. Using ALTO for CDNs 542 Section 3 discussed the placement and usage of ALTO for P2P systems, 543 but not beyond. This section discuss the usage of ALTO for Content 544 Delivery Networks (CDNs). CDNs are used to bring a service (e.g., a 545 web page, videos, etc) closer to the location of the user - where 546 close refers to shorten the distance between the client and the 547 server in the IP topology. CDNs use several techniques to decide 548 which server is closest to a client requesting a service. One common 549 way to do so, is relying on the DNS system, but there are many other 550 ways, see [RFC3568]. 552 The general issue for CDNs, independent of DNS or HTTP Redirect based 553 approaches (see, for instance, [I-D.penno-alto-cdn]), is that the CDN 554 logic has to match the client's IP address with the closest CDN 555 cache. This matching is not trivial, for instance, in DNS based 556 approaches, where the IP address of the DNS original requester is 557 unknown (see [I-D.vandergaast-edns-client-ip] for a discussion of 558 this and a solution approach). 560 5. Cascading ALTO Servers 562 The main assumptions of ALTO seems to be each ISP operates its own 563 ALTO server independently, irrespectively of the ISP's situation. 564 This may true for most envisioned deployments of ALTO but there are 565 certain deployments that may have different settings. Figure 13 566 shows such setting, were for example, a university network is 567 connected to two upstream providers. ISP2 if the national research 568 network and ISP1 is a commercial upstream provider to this university 569 network. The university, as well as ISP1, are operating their own 570 ALTO server. The ALTO clients, located on the peers will contact the 571 ALTO server located at the university. 573 +-----------+ 574 | ISP1 | 575 | ALTO | 576 | Server | 577 +----------=+ 578 ,-------= ,------. 579 ,-' =`-. ,-' `-. 580 / Upstream= \ / Upstream \ 581 ( ISP1 = ) ( ISP2 ) 582 \ = / \ / 583 `-. =,-' `-. ,-' 584 `---+---= `+------' 585 | = | 586 | ======================= 587 |,-------------. | = 588 ,-+ `-+ +-----------+ 589 ,' University `. |University | 590 ( Network ) | ALTO | 591 `. =======================| Server | 592 `-= +-' +-----------+ 593 =`+------------'| 594 = | | 595 +--------+-+ +-+--------+ 596 | Peer1 | | PeerN | 597 +----------+ +----------+ 599 Figure 13: Cascaded ALTO Server 601 In this setting all "destinations" useful for the peers within ISP2 602 are free-of-charge for the peers located in the university network 603 (i.e., they are preferred in the rating of the ALTO server). 604 However, all traffic that is not towards ISP2 will be handled by the 605 ISP1 upstream provider. Therefore, the ALTO server at the university 606 has also to include the guidance given by the ISP1 ALTO server in its 607 replies to the ALTO clients. This can be called cascaded ALTO 608 servers. 610 6. Known Limitations of ALTO 612 This section describes some known limitations of ALTO in general or 613 specific mechanisms in ALTO. 615 6.1. Limitations of Map-based Approaches 617 The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses, 618 amongst others mechanism, so-called network maps. The network map 619 approach uses Host Group Descriptors that group one or multiple 620 subnetworks (i.e., IP prefixes) to a single Host Group Descriptor. A 621 set of IP prefixes is called partition and the associated Host Group 622 Descriptor is called partition ID. The "costs" between the various 623 partition IDs is stored in a second map, the cost map. Map-based 624 approaches are chosen as they lower the signaling load on the server, 625 as the maps have only to be retrieved if they are changed. 627 The main assumption for map-based approaches is that the information 628 provided in these maps is static for a longer period of time, where 629 this period of time refers to days, but not hours or even minutes. 630 This assumption is fine, as long as the network operator does not 631 change any parameter, e.g., routing within the network and to the 632 upstream peers, IP address assignment stays stable (and thus the 633 mapping to the partitions). However, there are several cases where 634 this assumption is not valid, as: 636 1. ISPs reallocate IPv4 subnets from time to time; 638 2. ISPs reallocate IPv4 subnets on short notice; 640 3. IP prefix blocks may be assigned to a single DSLAM which serves a 641 variety of access networks. 643 For 1): ISPs reallocate IPv4 subnets within their infrastructure from 644 time to time, partly to ensure the efficient usage of IPv4 addresses 645 (a scarce resource), and partly to enable efficient route tables 646 within their network routers. The frequency of these "renumbering 647 events" depend on the growth in number of subscribers and the 648 availability of address space within the ISP. As a result, a 649 subscriber's household device could retain an IPv4 address for as 650 short as a few minutes, or for months at a time or even longer. 652 Some folks have suggested that ISPs providing ALTO services could 653 sub-divide their subscribers' devices into different IPv4 subnets 654 (or certain IPv4 address ranges) based on the purchased service 655 tier, as well as based on the location in the network topology. 656 The problem is that this sub-allocation of IPv4 subnets tends to 657 decrease the efficiency of IPv4 address allocation. A growing ISP 658 that needs to maintain high efficiency of IPv4 address utilization 659 may be reluctant to jeopardize their future acquisition of IPv4 660 address space. 662 However, this is not an issue for map-based approaches if changes are 663 applied in the order of days. 665 For 2): ISPs can use techniques, such as ODAP (XXX) that allow the 666 reallocation of IP prefixes on very short notice, i.e., within 667 minutes. An IP prefix that has no IP address assignment to a host 668 anymore can be reallocate to areas where there is currently a high 669 demand for IP addresses. 671 For 3): In DSL-based access networks, IP prefixes are assigned to 672 DSLAMs which are the first IP-hop in the access-network between the 673 CPE and the Internet. The access-network between CPE and DSLAM 674 (called aggregation network) can have varying characteristics (and 675 thus associated costs), but still using the same IP prefix. For 676 instance one IP addresses IP11 out of a IP prefix IP1 can be assigned 677 to a VDSL (e.g., 2 MBit/s uplink) access-line while the subsequent IP 678 address IP12 is assigned to a slow ADSL line (e.g., 128 kbit/s 679 uplink). These IP addresses are assigned on a first come first 680 served basis, i.e., the a single IP address out of the same IP prefix 681 can change its associated costs quite fast. This may not be an issue 682 with respect to the used upstream provider (thus the cross ISP 683 traffic) but depending on the capacity of the aggregation-network 684 this may raise to an issue. 686 6.2. Limitiations of Non-Map-based Approaches 688 The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses, 689 amongst others mechanism, a mechanism called Endpoint Cost Service. 690 ALTO clients can ask guidance for specific IP addresses to the ALTO 691 server. However, asking for IP addresses, asking with long lists of 692 IP addresses, and asking quite frequent may overload the ALTO server. 693 The server has to rank each received IP address which causes load at 694 the server. This may be amplified by the fact that not only a single 695 ALTO client is asking for guidance, but a larger number of them. 697 Caching of IP addresses at the ALTO client or the usage of the H12 698 approach [I-D.kiesel-alto-h12] in conjunction with caching may lower 699 the query load on the ALTO server. 701 6.3. General Challenges 703 An ALTO server stores information about preferences (e.g., a list of 704 preferred autonomous systems, IP ranges, etc) and ALTO clients can 705 retrieve these preferences. However, there are basically two 706 different approaches on where the preferences are actually processed: 708 1. The ALTO server has a list of preferences and clients can 709 retrieve this list via the ALTO protocol. This preference list 710 can be partially updated by the server. The actual processing of 711 the data is done on the client and thus there is no data of the 712 client's operation revealed to the ALTO server . 714 2. The ALTO server has a list of preferences or preferences 715 calculated during runtime and the ALTO client is sending 716 information of its operation (e.g., a list of IP addresses) to 717 the server. The server is using this operational information to 718 determine its preferences and returns these preferences (e.g., a 719 sorted list of the IP addresses) back to the ALTO client. 721 Approach 1 (we call it H1) has the advantage (seen from the client) 722 that all operational information stays within the client and is not 723 revealed to the provider of the server. On the other hand, does 724 approach 1 require that the provider of the ALTO server, i.e., the 725 network operator, reveals information about its network structure 726 (e.g., AS numbers, IP ranges, topology information in general) to the 727 ALTO client. 729 Approach 2 (we call it H2) has the advantage (seen from the operator) 730 that all operational information stays with the ALTO server and is 731 not revealed to the ALTO client. On the other hand, does approach 2 732 require that the clients send their operational information to the 733 server. 735 Both approaches have their pros and cons and are extensively 736 discussed on the ALTO mailing list. But there is basically a 737 dilemma: Approach 1 is seen as the only working solution by peer-to- 738 peer software vendors and approach 2 is seen as the only working by 739 the network operators. But neither the software vendors nor the 740 operators seem to willing to change their position. However, there 741 is the need to get both sides on board, to come to a solution. 743 7. API between ALTO Client and Application 745 This sections gives some informational guidance on how the interface 746 between the actual application using the ALTO guidance and the ALTO 747 client can look like. 749 This is still TBD. 751 8. Extensions to the ALTO Protocol 753 8.1. Host Group Descriptors 755 Host group descriptors are used in the ALTO client protocol to 756 describe the location of a host in the network topology. The ALTO 757 client protocol specification defines a basic set of host group 758 descriptor types, which have to be supported by all implementations, 759 and an extension procedure for adding new descriptor types . The 760 following list gives an overview on further host group descriptor 761 types that have been proposed in the past, or which are in use by 762 ALTO-related prototype implementations. This list is not intended as 763 normative text. Instead, the only purpose of the following list is 764 to document the descriptor types that have been proposed so far, and 765 to solicit further feedback and discussion: 767 o Autonomous System (AS) number 769 o Protocol-specific group identifiers, which expand to a set of IP 770 address ranges (CIDR) and/or AS numbers. In one specific solution 771 proposal, these are called Partition ID (PID). 773 8.2. Rating Criteria 775 Rating criteria are used in the ALTO client protocol to express 776 topology- or connectivity-related properties, which are evaluated in 777 order to generate the ALTO guidance. The ALTO client protocol 778 specification defines a basic set of rating criteria, which have to 779 be supported by all implementations, and an extension procedure for 780 adding new criteria . The following list gives an overview on 781 further rating criteria that have been proposed in the past, or which 782 are in use by ALTO-related prototype implementations. This list is 783 not intended as normative text. Instead, the only purpose of the 784 following list is to document the rating criteria that have been 785 proposed so far, and to solicit further feedback and discussion: 787 8.2.1. Distance-related Rating Criteria 789 o Relative topological distance: relative means that a larger 790 numerical value means greater distance, but it is up to the ALTO 791 service how to compute the values, and the ALTO client will not be 792 informed about the nature of the information. One way of 793 generating this kind of information MAY be counting AS hops, but 794 when querying this parameter, the ALTO client MUST NOT assume that 795 the numbers actually are AS hops. 797 o Absolute topological distance, expressed in the number of 798 traversed autonomous systems (AS). 800 o Absolute topological distance, expressed in the number of router 801 hops (i.e., how much the TTL value of an IP packet will be 802 decreased during transit). 804 o Absolute physical distance, based on knowledge of the approximate 805 geolocation (continent, country) of an IP address. 807 8.2.2. Charging-related Rating Criteria 809 o Traffic volume caps, in case the Internet access of the resource 810 consumer is not charged by "flat rate". For each candidate 811 resource provider, the ALTO service could indicate the amount of 812 data that may be transferred from/to this resource provider until 813 a given point in time, and how much of this amount has already 814 been consumed. Furthermore, it would have to be indicated how 815 excess traffic would be handled (e.g., blocked, throttled, or 816 charged separately at an indicated price). The interaction of 817 several applications running on a host, out of which some use this 818 criterion while others don't, as well as the evaluation of this 819 criterion in resource directories, which issue ALTO queries on 820 behalf of other peers, are for further study. 822 8.2.3. Performance-related Rating Criteria 824 The following rating criteria are subject to the remarks below. 826 o The minimum achievable throughput between the resource consumer 827 and the candidate resource provider, which is considered useful by 828 the application (only in ALTO queries), or 830 o An arbitrary upper bound for the throughput from/to the candidate 831 resource provider (only in ALTO responses). This may be, but is 832 not necessarily the provisioned access bandwidth of the candidate 833 resource provider. 835 o The maximum round-trip time (RTT) between resource consumer and 836 the candidate resource provider, which is acceptable for the 837 application for useful communication with the candidate resource 838 provider (only in ALTO queries), or 840 o An arbitrary lower bound for the RTT between resource consumer and 841 the candidate resource provider (only in ALTO responses). This 842 may be, for example, based on measurements of the propagation 843 delay in a completely unloaded network. 845 The ALTO client MUST be aware, that with high probability, the actual 846 performance values differ significantly from these upper and lower 847 bounds. In particular, an ALTO client MUST NOT consider the "upper 848 bound for throughput" parameter as a permission to send data at the 849 indicated rate without using congestion control mechanisms. 851 The discrepancies are due to various reasons, including, but not 852 limited to the facts that 854 o the ALTO service is not an admission control system 856 o the ALTO service may not know the instantaneous congestion status 857 of the network 859 o the ALTO service may not know all link bandwidths, i.e., where the 860 bottleneck really is, and there may be shared bottlenecks 862 o the ALTO service may not know whether the candidate peer itself is 863 overloaded 865 o the ALTO service may not know whether the candidate peer throttles 866 the bandwidth it devotes for the considered application 868 o the ALTO service may not know whether the candidate peer will 869 throttle the data it sends to us (e.g., because of some fairness 870 algorithm, such as tit-for-tat) 872 Because of these inaccuracies and the lack of complete, instantaneous 873 state information, which are inherent to the ALTO service, the 874 application must use other mechanisms (such as passive measurements 875 on actual data transmissions) to assess the currently achievable 876 throughput, and it MUST use appropriate congestion control mechanisms 877 in order to avoid a congestion collapse. Nevertheless, these rating 878 criteria may provide a useful shortcut for quickly excluding 879 candidate resource providers from such probing, if it is known in 880 advance that connectivity is in any case worse than what is 881 considered the minimum useful value by the respective application. 883 8.2.4. Inappropriate Rating Criteria 885 Rating criteria that SHOULD NOT be defined for and used by the ALTO 886 service include: 888 o Performance metrics that are closely related to the instantaneous 889 congestion status. The definition of alternate approaches for 890 congestion control is explicitly out of the scope of ALTO. 891 Instead, other appropriate means, such as using TCP based 892 transport, have to be used to avoid congestion. 894 9. Security Considerations 896 The ALTO protocol itself, as well as, the ALTO client and server 897 raise new security issues beyond the one mentioned in 898 [I-D.ietf-alto-protocol] and issues related to message transport over 899 the Internet. For instance, Denial of Service (DoS) is of interest 900 for the ALTO server and also for the ALTO client. A server can get 901 overloaded if too many TCP requests hit the server, or if the query 902 load of the server surpasses the maximum computing capacity. An ALTO 903 client can get overloaded if the responses from the sever are, either 904 intentionally or due to an implementation mistake, too large to be 905 handled by that particular client. 907 9.1. Information Leakage from the ALTO Server 909 The ALTO server will be provisioned with information about the owning 910 ISP's network and very likely also with information about neighboring 911 ISPs. This information (e.g., network topology, business relations, 912 etc) is consider to be confidential to the ISP and must not be 913 revealed. 915 The ALTO server will naturally reveal parts of that information in 916 small doses to peers, as the guidance given will depend on the above 917 mentioned information. This is seen beneficial for both parties, 918 i.e., the ISP's and the peer's. However, there is the chance that 919 one or multiple peers are querying an ALTO server with the goal to 920 gather information about network topology or any other data 921 considered confidential or at least sensitive. It is unclear whether 922 this is a real technical security risk or whether this is more a 923 perceived security risk. 925 9.2. ALTO Server Access 927 Depending on the use case of ALTO, several access restrictions to an 928 ALTO server may or may not apply. For an ALTO server that is solely 929 accessible by peers from the ISP network (as shown in Figure 9), for 930 instance, the source IP address can be used to grant only access from 931 that ISP network to the server. This will "limit" the number of 932 peers able to attack the server to the user's of the ISP (however, 933 including botnet computers). 935 On the other hand, if the ALTO server has to be accessible by parties 936 not located in the ISP's network (see Figure Figure 8), e.g., by a 937 third-party tracker or by a CDN system outside the ISP's network, the 938 access restrictions have to be more loose. In the extreme case, 939 i.e., no access restrictions, each and every host in the Internet can 940 access the ALTO server. This might no the intention of the ISP, as 941 the server is not only subject to more possible attacks, but also on 942 the load imposed to the server, i.e., possibly more ALTO clients to 943 serve and thus more work load. 945 9.3. Faking ALTO Guidance 947 It has not yet been investigated how a faked or wrong ALTO guidance 948 by an ALTO server can impact the operation of the network and also 949 the peers. 951 Here is a list of examples how the ALTO guidance could be faked and 952 what possible consequences may arise: 954 Sorting An attacker could change to sorting order of the ALTO 955 guidance (given that the order is of importance, otherwise the 956 ranking mechanism is of interest), i.e., declaring peers located 957 outside the ISP as peers to be preferred. This will not pose a 958 big risk to the network or peers, as it would mimic the "regular" 959 peer operation without traffic localization, apart from the 960 communication/processing overhead for ALTO. However, it could 961 mean that ALTO is reaching the opposite goal of shuffling more 962 data across ISP boundaries, incurring more costs for the ISP. 964 Preference of a single peer A single IP address (thus a peer) could 965 be marked as to be preferred all over other peers. This peer can 966 be located within the local ISP or also in other parts of the 967 Internet (e.g., a web server). This could lead to the case that 968 quite a number of peers to trying to contact this IP address, 969 possibly causing a Denial of Service (DoS) attack. 971 This section is solely giving a first shot on security issues related 972 to ALTO deployments. 974 10. Conclusion 976 This is the first version of the deployment considerations and for 977 sure the considerations are yet incomplete and imprecise. 979 11. References 981 11.1. Normative References 983 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 984 Requirement Levels", BCP 14, RFC 2119, March 1997. 986 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 987 Content Network (CN) Request-Routing Mechanisms", 988 RFC 3568, July 2003. 990 11.2. Informative References 992 [I-D.ietf-alto-protocol] 993 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 994 draft-ietf-alto-protocol-06 (work in progress), 995 October 2010. 997 [I-D.ietf-alto-reqs] 998 Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 999 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 1000 Requirements", draft-ietf-alto-reqs-07 (work in progress), 1001 January 2011. 1003 [I-D.kamei-p2p-experiments-japan] 1004 Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "ALTO- 1005 Like Activities and Experiments in P2P Network Experiment 1006 Council", draft-kamei-p2p-experiments-japan-04 (work in 1007 progress), November 2010. 1009 [I-D.kiesel-alto-3pdisc] 1010 Kiesel, S., Tomsu, M., Schwan, N., Scharf, M., and M. 1011 Stiemerling, "ALTO Server Discovery Protocol", 1012 draft-kiesel-alto-3pdisc-04 (work in progress), 1013 October 2010. 1015 [I-D.kiesel-alto-h12] 1016 Kiesel, S. and M. Stiemerling, "ALTO H12", 1017 draft-kiesel-alto-h12-02 (work in progress), March 2010. 1019 [I-D.penno-alto-cdn] 1020 Penno, R., Raghunath, S., Medved, J., Alimi, R., Yang, R., 1021 and S. Previdi, "ALTO and Content Delivery Networks", 1022 draft-penno-alto-cdn-02 (work in progress), October 2010. 1024 [I-D.vandergaast-edns-client-ip] 1025 Contavalli, C., Gaast, W., Leach, S., and D. Rodden, 1026 "Client IP information in DNS requests", 1027 draft-vandergaast-edns-client-ip-01 (work in progress), 1028 May 2010. 1030 [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and 1031 Y. Yang, "Comcast's ISP Experiences in a Proactive Network 1032 Provider Participation for P2P (P4P) Technical Trial", 1033 RFC 5632, September 2009. 1035 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1036 Optimization (ALTO) Problem Statement", RFC 5693, 1037 October 2009. 1039 Appendix A. Acknowledgments 1041 Martin Stiemerling is partially supported by the NAPA-WINE project 1042 (Network-Aware P2P-TV Application over Wise Networks, 1043 http://www.napa-wine.org), a research project supported by the 1044 European Commission under its 7th Framework Program (contract no. 1045 214412). The views and conclusions contained herein are those of the 1046 authors and should not be interpreted as necessarily representing the 1047 official policies or endorsements, either expressed or implied, of 1048 the NAPA-WINE project or the European Commission. 1050 Authors' Addresses 1052 Martin Stiemerling 1053 NEC Laboratories Europe/University of Goettingen 1054 Kurfuerstenanlage 36 1055 Heidelberg 69115 1056 Germany 1058 Phone: +49 6221 4342 113 1059 Fax: +49 6221 4342 155 1060 Email: martin.stiemerling@neclab.eu 1061 URI: http://ietf.stiemerling.org 1063 Sebastian Kiesel 1064 University of Stuttgart, Computing Center 1065 Allmandring 30 1066 Stuttgart 70550 1067 Germany 1069 Email: ietf-alto@skiesel.de