idnits 2.17.1 draft-ietf-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 184 has weird spacing: '...logical ser...' == Line 212 has weird spacing: '...logical ser...' == Line 552 has weird spacing: '...layered fixed...' == Line 816 has weird spacing: '...art for resou...' == Line 897 has weird spacing: '... and n! ...' == 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 (February 25, 2013) is 4071 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 1664, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-13 == Outdated reference: A later version (-10) exists of draft-ietf-alto-server-discovery-07 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, Ed. 3 Internet-Draft NEC Europe Ltd. 4 Intended status: Informational S. Kiesel, Ed. 5 Expires: August 29, 2013 University of Stuttgart 6 S. Previdi 7 Cisco. 8 February 25, 2013 10 ALTO Deployment Considerations 11 draft-ietf-alto-deployments-06 13 Abstract 15 Many Internet applications are used to access resources, such as 16 pieces of information or server processes, which are available in 17 several equivalent replicas on different hosts. This includes, but 18 is not limited to, peer-to-peer file sharing applications. The goal 19 of Application-Layer Traffic Optimization (ALTO) is to provide 20 guidance to these applications, which have to select one or several 21 hosts from a set of candidates, that are able to provide a desired 22 resource. The protocol is under specification in the ALTO working 23 group. This memo discusses deployment related issues of ALTO for 24 peer-to-peer and CDNs, some preliminary security considerations, and 25 also initial guidance for application designers using ALTO. 27 Status of this Memo 29 This Internet-Draft is submitted 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). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on August 29, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. General Considerations . . . . . . . . . . . . . . . . . . . . 5 63 2.1. General Placement of ALTO . . . . . . . . . . . . . . . . 5 64 2.2. Relationship between ALTO and Applications . . . . . . . . 7 65 2.3. Provided Guidance . . . . . . . . . . . . . . . . . . . . 7 66 2.3.1. Keeping Traffic Local in Network . . . . . . . . . . . 8 67 2.3.2. Off-Loading Traffic from Network . . . . . . . . . . . 8 68 2.3.3. Intra-Network Localization/Bottleneck Off-Loading . . 9 69 2.4. Provisiong ALTO Maps . . . . . . . . . . . . . . . . . . . 11 70 3. Deployment Considerations by ISPs . . . . . . . . . . . . . . 12 71 3.1. Requirement for Traffic Optimization by ISPs . . . . . . . 12 72 3.2. Considerations for ISPs . . . . . . . . . . . . . . . . . 13 73 3.2.1. Very small ISPs with simple Network Structure . . . . 13 74 3.2.2. Large ISPs with layered fixed Network Structure . . . 13 75 3.2.3. ISPs with Mobile Network . . . . . . . . . . . . . . . 15 76 4. Using ALTO for P2P . . . . . . . . . . . . . . . . . . . . . . 17 77 4.1. Using ALTO for Tracker-based Peer-to-Peer Applications . . 19 78 4.2. Expectations of ALTO . . . . . . . . . . . . . . . . . . . 24 79 5. Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . . 25 80 5.1. Request Routing using the Endpoint Cost Service . . . . . 25 81 5.1.1. ALTO Topology Vs. Network Topology . . . . . . . . . . 26 82 5.1.2. Topology Computation and ECS Delivery . . . . . . . . 26 83 5.1.3. Ranking Service . . . . . . . . . . . . . . . . . . . 26 84 5.1.4. Ranking and Network Events . . . . . . . . . . . . . . 27 85 5.1.5. Caching and Lifetime . . . . . . . . . . . . . . . . . 27 86 5.1.6. Redirection . . . . . . . . . . . . . . . . . . . . . 28 87 5.1.7. Groups and Costs . . . . . . . . . . . . . . . . . . . 28 88 6. Advanced Features . . . . . . . . . . . . . . . . . . . . . . 29 89 6.1. Cascading ALTO Servers . . . . . . . . . . . . . . . . . . 29 90 6.2. ALTO for IPv4 and IPv6 . . . . . . . . . . . . . . . . . . 30 91 6.3. Monitoring ALTO . . . . . . . . . . . . . . . . . . . . . 30 92 6.3.1. Monitoring Metrics Definition . . . . . . . . . . . . 30 93 6.3.2. Monitoring Data Sources . . . . . . . . . . . . . . . 31 94 6.3.3. Monitoring Structure . . . . . . . . . . . . . . . . . 31 95 7. Known Limitations of ALTO . . . . . . . . . . . . . . . . . . 33 96 7.1. Limitations of Map-based Approaches . . . . . . . . . . . 33 97 7.2. Limitiations of Non-Map-based Approaches . . . . . . . . . 34 98 7.3. General Challenges . . . . . . . . . . . . . . . . . . . . 34 99 8. Extensions to the ALTO Protocol . . . . . . . . . . . . . . . 36 100 8.1. Host Group Descriptors . . . . . . . . . . . . . . . . . . 36 101 8.2. Rating Criteria . . . . . . . . . . . . . . . . . . . . . 36 102 8.2.1. Distance-related Rating Criteria . . . . . . . . . . . 36 103 8.2.2. Charging-related Rating Criteria . . . . . . . . . . . 37 104 8.2.3. Performance-related Rating Criteria . . . . . . . . . 37 105 8.2.4. Inappropriate Rating Criteria . . . . . . . . . . . . 38 106 9. API between ALTO Client and Application . . . . . . . . . . . 39 107 10. Security Considerations . . . . . . . . . . . . . . . . . . . 40 108 10.1. Information Leakage from the ALTO Server . . . . . . . . . 40 109 10.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 40 110 10.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 41 111 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 42 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 113 12.1. Normative References . . . . . . . . . . . . . . . . . . . 43 114 12.2. Informative References . . . . . . . . . . . . . . . . . . 43 115 Appendix A. Contributors List and Acknowledgments . . . . . . . . 45 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 118 1. Introduction 120 Many Internet applications are used to access resources, such as 121 pieces of information or server processes, which are available in 122 several equivalent replicas on different hosts. This includes, but 123 is not limited to, peer-to-peer file sharing applications and Content 124 Delivery Networks (CDNs). The goal of Application-Layer Traffic 125 Optimization (ALTO) is to provide guidance to applications, which 126 have to select one or several hosts from a set of candidates, that 127 are able to provide a desired resource. The basic ideas of ALTO are 128 described in the problem space of ALTO is described in [RFC5693] and 129 the set of requirements is discussed in [RFC6708]. 131 However, there are no considerations about what operational issues 132 are to be expected once ALTO will be deployed. This includes, but is 133 not limited to, location of the ALTO server, imposed load to the ALTO 134 server, or from whom the queries are performed. 136 Comments and discussions about this memo should be directed to the 137 ALTO working group: alto@ietf.org. 139 2. General Considerations 141 The ALTO protocol is a client/server protocol, operating between a 142 number of ALTO clients and an ALTO server, as sketched in Figure 1. 143 The ALTO working groups defines the ALTO protocol 144 [I-D.ietf-alto-protocol]. 146 +----------+ 147 | ALTO | 148 | Server | 149 +----------+ 150 ^ 151 _.-----|------. 152 ,-'' | `--. 153 ,' | `. 154 ( Network | ) 155 `. | ,' 156 `--. | _.-' 157 `------|-----'' 158 v 159 +----------+ +----------+ +----------+ 160 | ALTO | | ALTO |...| ALTO | 161 | Client | | Client | | Client | 162 +----------+ +----------+ +----------+ 164 Figure 1: Network Overview of ALTO Protocol 166 2.1. General Placement of ALTO 168 The ALTO server and ALTO clients can be situated at various entities 169 in a network deployment. The first differentiation is whether the 170 ALTO client is located on the actual host that runs the application, 171 as shown in Figure 2, (e.g., peer-to-peer filesharing application) or 172 if the ALTO client is located on resource directory, as shown in 173 Figure 3 (e.g., a tracker in peer-to-peer filesharing). 175 +-----+ 176 =====| |** 177 ==== +-----+ * 178 ==== * * 179 ==== * * 180 +-----+ +------+===== +-----+ * 181 | |.....| |======================| | * 182 +-----+ +------+===== +-----+ * 183 Source of ALTO ==== * * 184 topological service ==== * * 185 information ==== +-----+ * 186 =====| |** 187 +-----+ 188 Legend: 189 === ALTO client protocol 190 *** Application protocol 191 ... Provisioning protocol 193 Figure 2: Overview of protocol interaction between ALTO 194 elements,scenario without tracker 196 Figure 2 shows the operational model for applications that do not use 197 a tracker, such as, edonky, or in if the tracker should be the 198 querying party. This use case also holds true for CDNs. The ALTO 199 server can also be queried by CDNs to get a guidance about where the 200 a particular client accessing data in the CDN is exactly located in 201 the ISP's network. 203 +-----+ 204 **| |** 205 ** +-----+ * 206 ** * * 207 ** * * 208 +-----+ +------+ +-----+** +-----+ * 209 | |.....| |=====| |**********| | * 210 +-----+ +------+ +-----+** +-----+ * 211 Source of ALTO Resource ** * * 212 topological service directory ** * * 213 information ("tracker") ** +-----+ * 214 **| |** 215 +-----+ 216 Peers 217 Legend: 218 === ALTO client protocol 219 *** Application protocol 220 ... Provisioning protocol 222 Figure 3: Overview of protocol interaction between ALTO elements, 223 scenario with tracker 225 However, Figure 3 does not denote where the ALTO elements are 226 actually located, i.e., if the tracker and the ALTO server are in the 227 same ISP's domain, or if the tracker and the ALTO server are managed/ 228 owned/located in different domains. The latter is the typical use 229 case, e.g., taking Pirate Bay as example that serves Bittorrent peers 230 world-wide. 232 2.2. Relationship between ALTO and Applications 234 ALTO is intended to be used by a wide-range of applications. 235 However, any application using ALTO must also work if no ALTO servers 236 can be found or if no responses to ALTO queries are received, e.g., 237 due to connectivity problems or overload situation (see also 238 [RFC6708]). (Editor's note: better text needed here!) 240 2.3. Provided Guidance 242 ALTO gives guidance to applications on what IP addresses or IP 243 prefixes, and such which hosts are to be preferred according to the 244 operator of the ALTO server. The general assumption of the ALTO WG 245 is that a network operator would always express to prefer hosts in 246 its own network while hosts located outside its own network are to be 247 avoided (are undesired to be considered by the applications). This 248 might be applicable in some cases but may not be applicable in the 249 general case. The ALTO protocol gives only the means to let the ALTO 250 server operator to express is preference, whatever this preference 251 is. This section explores this space. 253 2.3.1. Keeping Traffic Local in Network 255 ALTO guidance can be used to let applications prefer other peers 256 within the same network operator's network instead of randomly 257 connecting to other peers which are located in another operator's 258 network. Figure 4 shows such a scenario where peers prefer peers in 259 the same network (e.g., Peer 1 and Peer 2 in ISP1 and Peer 3 and Peer 260 4 in ISP2). 262 ,-------. +-----------+ 263 ,---. ,-' `-. | Peer 1 | 264 ,-' `-. / ISP 1 ########|ALTO Client| 265 / \ / # \ +-----------+ 266 / ISP X \ | # | +-----------+ 267 / \ \ ########| Peer 2 | 268 ; +----------------------------|ALTO Client| 269 | | | `-. ,-' +-----------+ 270 | | | `-------' 271 | | | ,-------. +-----------+ 272 : | ; ,-' `########| Peer 3 | 273 \ | / / ISP 2 # \ |ALTO Client| 274 \ | / / # \ +-----------+ 275 \ +---------+ # | +-----------+ 276 `-. ,-' \ | ########| Peer 4 | 277 `---' \ +------------------|ALTO Client| 278 `-. ,-' +-----------+ 279 `-------' 281 Legend: 282 ### preferred "connections" 283 --- non-preferred "connections" 285 Figure 4: ALTO Traffic Network Localization 287 TBD: Describes limits of this approach (e.g., traffic localization 288 guidance is of less use if the peers cannot upload); describe how 289 maps would look like. 291 2.3.2. Off-Loading Traffic from Network 293 Another scenario where the use of ALTO can be beneficial is in mobile 294 broadband networks, e.g., CDMA200 or UMTS, but where the network 295 operator may have the desire to guide peers in its own network to use 296 peers in remote networks. One reason can be that the wireless 297 network is not made for the load cause by, e.g., peer-to-peer 298 applications, and the operator has the need that peers fetch their 299 data from remote peers in other parts of the Internet. 301 ,-------. +-----------+ 302 ,---. ,-' `-. | Peer 1 | 303 ,-' `-. / ISP 1 +-------|ALTO Client| 304 / \ / | \ +-----------+ 305 / ISP X \ | | | +-----------+ 306 / \ \ +-------| Peer 2 | 307 ; #-###########################|ALTO Client| 308 | # | `-. ,-' +-----------+ 309 | # | `-------' 310 | # | ,-------. +-----------+ 311 : # ; ,-' `+-------| Peer 3 | 312 \ # / / ISP 2 | \ |ALTO Client| 313 \ # / / | \ +-----------+ 314 \ ########### | | +-----------+ 315 `-. ,-' \ # +-------| Peer 4 | 316 `---' \ ###################|ALTO Client| 317 `-. ,-' +-----------+ 318 `-------' 320 Legend: 321 === preferred "connections" 322 --- non-preferred "connections" 324 Figure 5: ALTO Traffic Network De-Localization 326 Figure 5 shows the result of such a guidance process where Peer 2 327 prefers a connection with Peer4 instead of Peer 1, as shown in 328 Figure 4. 330 TBD: Limits of this approach in general and with respect to p2p. 331 describe how maps would look like. 333 2.3.3. Intra-Network Localization/Bottleneck Off-Loading 335 The above sections described the results of the ALTO guidance on an 336 inter-network level. However, ALTO can also be used to guide peers 337 on which internal peers are to be preferred. For instance, to guide 338 Peers on a remote network side to prefer to connect to each other, 339 instead of crossing a bottleneck link, a backhaul link to connect the 340 side to the network core. Figure 6 shows such a scenario where Peer 341 1 and Peer 2 are located in Net 2 of ISP1 and connect via a low 342 capacity link to the core (Net 1) of the same ISP1. Peer1 and Peer 2 343 would both exchange their data with remote peers, probably clogging 344 the bottleneck link. 346 ,-------. +-----------+ 347 ,---. ,-' `-. | Peer 1 | 348 ,-' `-. / ISP 1 #########|ALTO Client| 349 / \ / Net 2 # \ +-----------+ 350 / ISP 1 \ | ######### | +-----------+ 351 / Net 1 \ \ # / | Peer 2 | 352 ; ###; \ # ##########|ALTO Client| 353 | X~~~~~~~~~~~~X#######,-' +-----------+ 354 | ### | ^ `-------' 355 | | | 356 : ; | 357 \ / Bottleneck 358 \ / 359 \ / 360 `-. ,-' 361 `---' 362 Legend: 363 ### peer "connections" 364 ~~~ bottleneck link 366 Figure 6: Without Intra-Network ALTO Traffic Localization 368 The operator can guide the peers in such a situation to try first 369 local peers in the same network islands, avoiding or at least 370 lowering the effect on the bottleneck link, as shown in Figure 7. 372 ,-------. +-----------+ 373 ,---. ,-' `-. | Peer 1 | 374 ,-' `-. / ISP 1 #########|ALTO Client| 375 / \ / Net 2 # \ +-----------+ 376 / ISP 1 \ | # | +-----------+ 377 / Net 1 \ \ #########| Peer 2 | 378 ; ; \ ##########|ALTO Client| 379 | #~~~~~~~~~~~########,-' +-----------+ 380 | ### | ^ `-------' 381 | | | 382 : ; | 383 \ / Bottleneck 384 \ / 385 \ / 386 `-. ,-' 387 `---' 388 Legend: 389 ### peer "connections" 390 ~~~ bottleneck link 392 Figure 7: With Intra-Network ALTO Traffic Localization 394 TBD: describe how maps would look like. 396 2.4. Provisiong ALTO Maps 398 This section will describe how ALTO maps in the protocol can be 399 populated before using them. 401 3. Deployment Considerations by ISPs 403 The Internet is a large network constituted of multiple networks 404 worldwide. Numerous of these networks are built by telecom operators 405 or network operators (named ISP in this memo), and these networks 406 provide network connectivity, such as cable networks, 3G and so on. 407 As well as some of networks are built by universities or big 408 organizations themselves, and these networks are used to provide 409 connectivity for research and work. The essence of Internet is its 410 connectivity and sharing capability. However, ISPs emphasize 411 network's manageability and controllability, because ISPs provide 412 public network access service for most person and families, they need 413 to manage, to control and to audit the traffic. Thus, it's important 414 for ISPs to understand the requirement of optimizing traffic, and how 415 to deploy ALTO service in these manageability and controllability 416 networks. 418 3.1. Requirement for Traffic Optimization by ISPs 420 All networks of ISPs are connected to each other through peering 421 points. From view of business mode, the inter-network settlement is 422 needed in traffic exchanging between these ISP's networks. The 423 current settlement can be costly. So to save these cost, the simple 424 and basic method is to decrease the traffic exchange across the 425 peering points and keep the traffic in own network area. 427 For some large ISPs, their whole network is layered. The upper layer 428 network includes one or several backbone networks, and the lower 429 layer network includes multiple access networks. These access 430 networks are connected to backbone networks, and the exchange traffic 431 with others through backbone network. In this kind of layered 432 network, the bandwidth of backbone network is important and may be 433 scarce. Traffic should be limited to the access networks, so to 434 decrease the usage of backbone as far as possible. 436 Compared to fixed networks, mobile networks have some special 437 characters, including small link bandwidth, high cost, limited radio 438 frequency resource, and terminal battery. In mobile network, the 439 usage of wireless link should be decreased as far as possible and be 440 high-efficient. For example, in the case of a P2P service, the 441 clients in the fixed network should decrease the data transport from 442 the clients in the mobile networks, as well as the clients in the 443 mobile networks should prefer the data transmission from the clients 444 in the fixed networks. 446 3.2. Considerations for ISPs 448 3.2.1. Very small ISPs with simple Network Structure 450 For very small ISPs, the traffic optimizing problem they focus is 451 that how to decrease the traffic exchanging with other ISPs, because 452 of high settlement costs. To use the ALTO service to optimize 453 traffic, small ISPs can define two optimization areas: one is their 454 own network; the other is all outer networks connected with their 455 network. The cost map can be defined like this: the cost of link 456 between clients of inner ISP's networks is lower than from clients of 457 outer ISP's networks to clients of inner ISP's networks. So the 458 client of this ISP will prefer to require data from the clients in 459 the same ISP with high priority. 461 One example is given as below in Figure 8. ISP A is one small ISP, 462 only having one access network. In ALTO service deploying, we can 463 define ISP A to be one optimization area, named as PID1, and define 464 other networks to be the other optimization area, named as PID2. C1 465 is denoted as the link cost in inner ISP A. C2 is denoted as the link 466 cost from PID2 to PID1. We define the cost map as: 468 C1|PID 2 |<----+PID 3 | | 544 | |C1 | |C2 | |C3 | | +----------------+ 545 | +---+--+ +---+--+ +-+----+ | | | 546 | | C7 | Other Networks | 547 | |<--------+ PID 5 | 548 | | | | 549 | | | | 550 +------------------------------------+ +----------------+ 552 Figure 9: ALTO deployment in large ISPs with layered fixed network 553 structures 555 3.2.3. ISPs with Mobile Network 557 For ISPs with mobile network and fixed network, the traffic 558 optimizing problems they focus will be optimizing the mobile traffic, 559 except problems on last hop section. Wireless radio frequency 560 resource is scarce and costly in mobile network. The requirement of 561 traffic optimization in mobile network is mainly decreasing the usage 562 of radio resource. The ALTO service can be deployed to meet these 563 needs. 565 For example in one ISP A as below in Figure 10, there is one mobile 566 network is connected to backbone network. In this kind of network 567 structure, mobile network can be defined as one optimization area, 568 and assigned PID 1. We also define other PID and cost as figure 569 below. 571 To decrease the usage of wireless link, the relationship of these 572 costs will be defined to: 574 From view of mobile network:(C4 < C1). This means that, the clients 575 in mobile network requiring data resource from clients of the other 576 access networks is prior to clients of mobile network. This policy 577 can decrease the usage of wireless link and power consumption in 578 terminal. 580 From view of AN A:(C2 < C6, C5 = maximum cost). This means that, to 581 other optimization area, requiring data from mobile network should be 582 avoided. 584 +-----------------------------------------------------------------+ 585 | | 586 | ISP A +-------------+ | 587 | +--------+ ALTO +---------+ | 588 | | | Service | | | 589 | | +------+------+ | | 590 | | | | | 591 | | | | | 592 | | | | | 593 | +-------+-------+ | C6 +--------+------+ | 594 | | AN A |<-------------- AN B | | 595 | | PID 2 | C7 | | PID 3 | | 596 | | C2 -------------->| C3 | | 597 | +---------------+ | +---------------+ | 598 | ^ | | | ^ | 599 | | | | | | | 600 | | |C4 | | | | 601 | C5 | | | | | | 602 | | | +--------+---------+ | | | 603 | | +-->| Mobile Network |<---+ | | 604 | | | PID 1 | | | 605 | +------- | C1 |----------+ | 606 | +------------------+ | 607 +-----------------------------------------------------------------+ 609 Figure 10: ALTO deployment in ISPs with mobile network 611 4. Using ALTO for P2P 612 ,-------. 613 ,---. ,-' `-. +-----------+ 614 ,-' `-. / ISP 1 \ | Peer 1 |***** 615 / \ / +-------------+ \ | | * 616 / ISP X \ +=====>+ ALTO Server | )+-----------+ * 617 / \ = \ +-------------+ / +-----------+ * 618 ; +-----------+ : = \ / | Peer 2 | * 619 | | Tracker |<====+ `-. ,-' | |***** 620 | |ALTO Client|<====+ `-------' +-----------+ ** 621 | +-----------+ | = ,-------. ** 622 : * ; = ,-' `-. +-----------+ ** 623 \ * / = / ISP 2 \ | Peer 3 | ** 624 \ * / = / +-------------+ \ | |***** 625 \ * / +=====>| ALTO Server | )+-----------+ *** 626 `-. * ,-' \ +-------------+ / +-----------+ *** 627 `-*-' \ / | Peer 4 |***** 628 * `-. ,-' | | **** 629 * `-------' +-----------+ **** 630 * **** 631 * **** 632 ***********************************************<****** 633 Legend: 634 === ALTO client protocol 635 *** Application protocol 637 Figure 11: Global tracker accessing ALTO server at various ISPs 639 Figure 11 depicts a tracker-based system, where the tracker embeds 640 the ALTO client. The tracker itself is hosted and operated by an 641 entity different than the ISP hosting and operating the ALTO server. 642 Initially, the tracker has to look-up the ALTO server in charge for 643 each peer where it receives a ALTO query for. Therefore, the ALTO 644 server has to discover the handling ALTO server, as described in 645 [I-D.ietf-alto-server-discovery]. However, the peers do not have any 646 way to query the server themselves. This setting allows to give the 647 peers a better selection of candidate peers for their operation at an 648 initial time, but does not consider peers learned through direct 649 peer-to-peer knowledge exchange. This is called peer exchange (PEX) 650 in bittorent, for instance. 652 ,-------. +-----------+ 653 ,---. ,-' `-. +==>| Peer 1 |***** 654 ,-' `-. / ISP 1 \ = |ALTO Client| * 655 / \ / +-------------+<=+ +-----------+ * 656 / ISP X \ | + ALTO Server |<=+ +-----------+ * 657 / \ \ +-------------+ /= | Peer 2 | * 658 ; +---------+ : \ / +==>|ALTO Client|***** 659 | | Global | | `-. ,-' +-----------+ ** 660 | | Tracker | | `-------' ** 661 | +---------+ | ,-------. +-----------+ ** 662 : * ; ,-' `-. +==>| Peer 3 | ** 663 \ * / / ISP 2 \ = |ALTO Client|***** 664 \ * / / +-------------+<=+ +-----------+ *** 665 \ * / | | ALTO Server |<=+ +-----------+ *** 666 `-. * ,-' \ +-------------+ /= | Peer 4 |***** 667 `-*-' \ / +==>|ALTO Client| **** 668 * `-. ,-' +-----------+ **** 669 * `-------' **** 670 * **** 671 ***********************************************<**** 672 Legend: 673 === ALTO client protocol 674 *** Application protocol 676 Figure 12: Global Tracker - Local ALTO Servers 678 The scenario in Figure 12 lets the peers directly communicate with 679 their ISP's ALTO server (i.e., ALTO client embedded in the peers), 680 giving thus the peers the most control on which information they 681 query for, as they can integrate information received from trackers 682 and through direct peer-to-peer knowledge exchange. 684 ,-------. +-----------+ 685 ,---. ,-' ISP 1 `-. ***>| Peer 1 | 686 ,-' `-. /+-------------+\ * | | 687 / \ / + Tracker |<** +-----------+ 688 / ISP X \ | +-----===-----+<** +-----------+ 689 / \ \ +-----===-----+ /* | Peer 2 | 690 ; +---------+ : \+ ALTO Server |/ ***>| | 691 | | Global | | +-------------+ +-----------+ 692 | | Tracker | | `-------' 693 | +---------+ | +-----------+ 694 : ^ ; ,-------. | Peer 3 | 695 \ * / ,-' ISP 2 `-. ***>| | 696 \ * / /+-------------+\ * +-----------+ 697 \ * / / + Tracker |<** +-----------+ 698 `-. *,-' | +-----===-----+ | | Peer 4 |<* 699 `---* \ +-----===-----+ / | | * 700 * \+ ALTO Server |/ +-----------+ * 701 * +-------------+ * 702 * `-------' * 703 *********************************************** 704 Legend: 705 === ALTO client protocol 706 *** Application protocol 708 Figure 13: P4P approach with local tracker and local ALTO server 710 There are some attempts to let ISP's to deploy their own trackers, as 711 shown in Figure 13. In this case, the client has no chance to get 712 guidance from the ALTO server, other than talking to the ISP's 713 tracker. However, the peers would have still chance the contact 714 other trackers, deployed by entities other than the peer's ISP. 716 Figure 13 and Figure 11 ostensibly take peers the possibility to 717 directly query the ALTO server, if the communication with the ALTO 718 server is not permitted for any reason. However, considering the 719 plethora of different applications of ALTO, e.g., multiple tracker 720 and non-tracker based P2P systems and or applications searching for 721 relays, it seems to be beneficial for all participants to let the 722 peers directly query the ALTO server. The peers are also the single 723 point having all operational knowledge to decide whether to use the 724 ALTO guidance and how to use the ALTO guidance. This is a preference 725 for the scenario depicted in Figure Figure 12. 727 4.1. Using ALTO for Tracker-based Peer-to-Peer Applications 729 The scope of this section is the interaction of peer-to-peer 730 applications that use a centralized resource directory ("tracker"), 731 with the ALTO service. In this scenario, the resource consumer 732 ("peer") asks the resource directory for a list of candidate resource 733 providers, which can provide the desired resource. 735 For efficiency reasons (i.e., message size), usually only a subset of 736 all resource providers known to the resource directory will be 737 returned to the resource consumer. Some or all of these resource 738 providers, plus further resource providers learned by other means 739 such as direct communication between peers, will be contacted by the 740 resource consumer for accessing the resource. The purpose of ALTO is 741 giving guidance on this peer selection, which is supposed to yield 742 better-than-random results. The tracker response as well as the ALTO 743 guidance are most beneficial in the initial phase after the resource 744 consumer has decided to access a resource, as long as only few 745 resource providers are known. Later, when the resource consumer has 746 already exchanged some data with other peers and measured the 747 transmission speed, the relative importance of ALTO may dwindle. 749 The ALTO protocol specification [I-D.ietf-alto-protocol] details how 750 an ALTO client can query an ALTO server for guiding information and 751 receive the corresponding replies. However, in the considered 752 scenario of a tracker-based P2P application, there are two 753 fundamentally different possibilities where to place the ALTO client: 755 1. ALTO client in the resource consumer ("peer") 757 2. ALTO client in the resource directory ("tracker") 759 In the following, both scenarios are compared in order to explain the 760 need for third-party ALTO queries. 762 In the first scenario (see Figure 15), the resource consumer queries 763 the resource directory for the desired resource (F1). The resource 764 directory returns a list of potential resource providers without 765 considering ALTO (F2). It is then the duty of the resource consumer 766 to invoke ALTO (F3/F4), in order to solicit guidance regarding this 767 list. 769 In the second scenario (see Figure 17), the resource directory has an 770 embedded ALTO client, which we will refer to as RDAC in this 771 document. After receiving a query for a given resource (F1) the 772 resource directory invokes the RDAC to evaluate all resource 773 providers it knows (F2/F3). Then it returns a, possibly shortened, 774 list containing the "best" resource providers to the resource 775 consumer (F4). 777 ............................. ............................. 778 : Tracker : : Peer : 779 : ______ : : : 780 : +-______-+ : : k good : 781 : | | +--------+ : P2P App. : +--------+ peers +------+ : 782 : | N | | random | : Protocol : | ALTO- |------>| data | : 783 : | known |====>| pre- |*************>| biased | | ex- | : 784 : | peers, | | selec- | : transmit : | peer |------>| cha- | : 785 : | M good | | tion | : n peer : | select | n-k | nge | : 786 : +-______-+ +--------+ : IDs : +--------+ bad p.+------+ : 787 :...........................: :.....^.....................: 788 | 789 | ALTO 790 | client protocol 791 __|___ 792 +-______-+ 793 | | 794 | ALTO | 795 | server | 796 +-______-+ 798 Figure 14: Tracker-based P2P Application with random peer 799 preselection 801 Peer w. ALTO cli. Tracker ALTO Server 802 --------+-------- --------+-------- --------+-------- 803 | F1 Tracker query | | 804 |======================>| | 805 | F2 Tracker reply | | 806 |<======================| | 807 | F3 ALTO client protocol query | 808 |---------------------------------------------->| 809 | F4 ALTO client protocol reply | 810 |<----------------------------------------------| 811 | | | 813 ==== Application protocol (i.e., tracker-based P2P app protocol) 814 ---- ALTO client protocol 816 Figure 15: Basic message sequence chart for resource consumer- 817 initiated ALTO query 819 ............................. ............................. 820 : Tracker : : Peer : 821 : ______ : : : 822 : +-______-+ : : : 823 : | | +--------+ : P2P App. : k good peers & +------+ : 824 : | N | | ALTO- | : Protocol : n-k bad peers | data | : 825 : | known |====>| biased |******************************>| ex- | : 826 : | peers, | | peer | : transmit : | cha- | : 827 : | M good | | select | : n peer : | nge | : 828 : +-______-+ +--------+ : IDs : +------+ : 829 :.....................^.....: :...........................: 830 | 831 | ALTO 832 | client protocol 833 __|___ 834 +-______-+ 835 | | 836 | ALTO | 837 | server | 838 +-______-+ 840 Figure 16: Tracker-based P2P Application with ALTO client in tracker 842 Peer Tracker w. RDAC ALTO Server 843 --------+-------- --------+-------- --------+-------- 844 | F1 Tracker query | | 845 |======================>| | 846 | | F2 ALTO cli. p. query | 847 | |---------------------->| 848 | | F3 ALTO cli. p. reply | 849 | |<----------------------| 850 | F4 Tracker reply | | 851 |<======================| | 852 | | | 854 ==== Application protocol (i.e., tracker-based P2P app protocol) 855 ---- ALTO client protocol 857 Figure 17: Basic message sequence chart for third-party ALTO query 859 Note: the message sequences depicted in Figure 15 and Figure 17 may 860 occur both in the target-aware and the target-independent query mode 861 (c.f. [RFC6708]). In the target-independent query mode no message 862 exchange with the ALTO server might be needed after the tracker 863 query, because the candidate resource providers could be evaluated 864 using a locally cached "map", which has been retrieved from the ALTO 865 server some time ago. 867 The problem with the first approach is, that while the resource 868 directory might know thousands of peers taking part in a swarm, the 869 list returned to the resource consumer is usually shortened for 870 efficiency reasons. Therefore, the "best" (in the sense of ALTO) 871 potential resource providers might not be contained in that list 872 anymore, even before ALTO can consider them. 874 For illustration, consider a simple model of a swarm, in which all 875 peers fall into one of only two categories: assume that there are 876 "good" ("good" in the sense of ALTO's better-than-random peer 877 selection, based on an arbitrary desired rating criterion) and "bad' 878 peers only. Having more different categories makes the maths more 879 complex but does not change anything to the basic outcome of this 880 analysis. ssume that the swarm has a total number of N peers, out of 881 which are M "good" and N-M "bad" peers, which are all known to the 882 tracker. A new peer wants to join the swarm and therefore asks the 883 tracker for a list of peers. 885 If, according to the first approach, the tracker randomly picks n 886 peers from the N known peers, the result can be described with the 887 hypergeometric distribution. The probability that the tracker reply 888 contains exactly k "good" peers (and n-k "bad" peers) is: 890 / m \ / N - m \ 891 \ k / \ n - k / 892 P(X=k) = --------------------- 893 / N \ 894 \ n / 896 / n \ n! 897 with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1 898 k! (n-k)! 900 The probability that the reply contains at most k "good" peers is: 901 P(X<=k)=P(X=0)+P(X=1)+..+P(X=k). 903 For example, consider a swarm with N=10,000 peers known to the 904 tracker, out of which M=100 are "good" peers. If the tracker 905 randomly selects n=100 peers, the formula yields for the reply: 906 P(X=0)=36%, P(X<=4)=99%. That is, with a probability of approx. 36% 907 this list does not contain a single "good" peer, and with 99% 908 probability there are only four or less of the "good" peers on the 909 list. Processing this list with the guiding ALTO information will 910 ensure that the few favorable peers are ranked to the top of the 911 list; however, the benefit is rather limited as the number of 912 favorable peers in the list is just too small. 914 Much better traffic optimization could be achieved if the tracker 915 would evaluate all known peers using ALTO, and return a list of 100 916 peers afterwards. This list would then include a significantly 917 higher fraction of "good" peers. (Note, that if the tracker returned 918 "good" peers only, there might be a risk that the swarm might 919 disconnect and split into several disjunct partitions. However, 920 finding the right mix of ALTO-biased and random peer selection is out 921 of the scope of this document.) 923 Therefore, from an overall optimization perspective, the second 924 scenario with the ALTO client embedded in the resource directory is 925 advantageous, because it is ensured that the addresses of the "best" 926 resource providers are actually delivered to the resource consumer. 927 An architectural implication of this insight is that the ALTO server 928 discovery procedures must support third-party discovery. That is, as 929 the tracker issues ALTO queries on behalf of the peer which contacted 930 the tracker, the tracker must be able to discover an ALTO server that 931 can give guidance suitable for the that respective peer. 933 4.2. Expectations of ALTO 935 This section hints to some recent experiments conducted with ALTO- 936 like deployments in Internet Service Provider (ISP) network's. NTT 937 performed tests with their HINT server implementation and dummy nodes 938 to gain insight on how an ALTO-like service influence a peer-to-peer 939 systems [I-D.kamei-p2p-experiments-japan]. The results of an early 940 experiment conducted in the Comcast network are documented 941 here[RFC5632] 943 5. Using ALTO for CDNs 945 Section 2 discussed the placement and usage of ALTO for P2P systems, 946 but not beyond. This section discuss the usage of ALTO for Content 947 Delivery Networks (CDNs). CDNs are used to bring a service (e.g., a 948 web page, videos, etc) closer to the location of the user - where 949 close refers to shorten the distance between the client and the 950 server in the IP topology. CDNs use several techniques to decide 951 which server is closest to a client requesting a service. One common 952 way to do so, is relying on the DNS system, but there are many other 953 ways, see [RFC3568]. 955 The general issue for CDNs, independent of DNS or HTTP Redirect based 956 approaches (see, for instance, [I-D.penno-alto-cdn]), is that the CDN 957 logic has to match the client's IP address with the closest CDN 958 cache. This matching is not trivial, for instance, in DNS based 959 approaches, where the IP address of the DNS original requester is 960 unknown (see [I-D.vandergaast-edns-client-ip] for a discussion of 961 this and a solution approach). 963 5.1. Request Routing using the Endpoint Cost Service 965 Alternatively, the Request Router may request the Endpoint service 966 from the ALTO client. 968 Specifically, the Request Router requests the Endpoint Cost Service 969 in order to rank/rate the content locations (i.e., IP addresses of 970 CDN nodes) based on their distance/cost (by default the Endpoint Cost 971 Service operates based on Routing Distance) from/to the user address. 973 Once the Request Router obtained from the ALTO Server the ranked list 974 of locations (for the specific user) it can incorporate this 975 information into its selection mechanisms in order to point the user 976 to the most appropriate location. 978 A Request Router that uses the Endpoint Cost Service may query the 979 ALTO Server for rankings of CDN Node IP addresses for each 980 interesting host and cache the results for later usage. 982 Maps Services and ECS deliver similar ALTO service by allowing the 983 CDN to optimize internal selection mechanisms. Both services deliver 984 similar level of security, confidentiality of layer-specific 985 information (i.e.: application and network) however, Maps and ECS 986 differ in the way the ALTO service is delivered and address a 987 different set of requirements in terms of topology information and 988 network operations. 990 5.1.1. ALTO Topology Vs. Network Topology 992 The ALTO server builds a ALTO-specific network topology that 993 represents the network as it should be understood and utilized by the 994 application layer (the CDN). Besides the security requirements that 995 consist of not delivering any confidential or critical information 996 about the infrastructure, there are efficiency requirements in terms 997 of what visibility of the network, and which level of granularity, it 998 is required by the CDN and more in general by the application layer. 1000 The ALTO server builds topology (for either Map and ECS services) 1001 based on multiple sources that may include: routing protocols, 1002 network policies, state and performance information, geo-location, 1003 etc. In all cases, the ALTO topology will not contain any details 1004 that would endanger the network integrity and security (e.g.: There 1005 will be no leaking of OSPF/ISIS/BGP databases to ALTO clients). 1007 5.1.2. Topology Computation and ECS Delivery 1009 ECS allows the CDN not to have to implement any specific algorithm or 1010 mechanism in order to retrieve, maintain and process network topology 1011 information (of any kind). The complexity of the network topology 1012 (computation, maintenance and distribution) is kept in the ALTO 1013 server and ECS is delivered on demand. Thus ECS is used in order to 1014 implement a lightweight integration of ALTO services in the CDN 1015 layer. ECS implies an ALTO and CDN implementation with the necessary 1016 scalability in order to cope with the amount of transactions that CDN 1017 and ALTO server will have to handle (knowing that the CDN is able to 1018 cache ALTO ECS results for further use). 1020 The ALTO server delivering ECS may integrate various information 1021 sources such as routing topology, policies, state and performance, 1022 geo-location, etc, and deliver the ranking service to the CDN upon 1023 request. The network topology information is controlled, managed by 1024 the ALTO server and the CDN benefits from ranking services in order 1025 to optimize application layer mechanisms used for content location 1026 selection. This allows the ALTO server to enhance and modify the way 1027 the topology information sources are used and combined without 1028 requiring any update in the mechanisms the ECS is delivered and do 1029 not require any update process between ALTO and the CDN. 1031 5.1.3. Ranking Service 1033 When a user request a given content, the CDN locates the content in 1034 one or more caches and executes a selection algorithms in order to 1035 redirect the user to the 'best' cache. In order to achieve that, the 1036 CDN issues an ECS request with the endpoint address (IPv4/IPv6) of 1037 the user (content requester) and the set of endpoint addresses of the 1038 content caches (content targets). The ALTO server, receives the 1039 request and ranks the list of content targets addresses based on 1040 their distance from the content requester. By default, according to 1041 [I-D.ietf-alto-protocol], the distance represents the routing cost as 1042 computed by the routing layer (OSPF, ISIS, BGP) and may take into 1043 consideration other routing criteria such as MPLS-VPN (MP-BGP) and 1044 MPLS-TE (RSVP), policy and state and performance information in 1045 addition to other information sources (policy, geo-location, state 1046 and performance). 1048 Once the ALTO server computed the distance it replies with the ranked 1049 list of content target addresses. The list being ranked by distance, 1050 the CDN is capable of integrating the rankings into its selection 1051 process (that will also incorporate other criteria) and redirect the 1052 user accordingly. 1054 5.1.4. Ranking and Network Events 1056 ALTO server ranks addresses based on topology information it acquires 1057 from the network. The different methods and algorithms through which 1058 the ALTO server computes topology information and rankings is out of 1059 the scope of this document. However, and in the case the rankings 1060 are based on routing (IP/MPLS) topology, it is obvious that network 1061 events may impact the ranking computation. The scope of the ECS 1062 service delivered to a CDN is not to maintain the CDN aware of any 1063 possible network topology changes since, due to redundancy of current 1064 networks, most of the network events happening in the infrastructure 1065 will have limited impact on the CDN. However, catastrophic events 1066 such as main trunks failures or backbone partition will have to take 1067 into account by the ALTO server so to redirect traffic away from the 1068 failure impacted area. 1070 5.1.5. Caching and Lifetime 1072 Each reply sent back by the ALTO server to the ALTO client running in 1073 the CDN has a validity in time so that the CDN can cache the results 1074 in order to re-use it and hence reducing the number of transactions 1075 between CDN and ALTO server. The ALTO server may indicate in the 1076 reply message how long the content of the message is to be considered 1077 reliable and insert a lifetime value that will be used by the CDN in 1078 order to cache (and then flush or refresh) the entry. 1080 An ALTO server implementation may want to keep state about ALTO 1081 clients so to inform and signal to these clients when a major network 1082 event happened so to clear the ALTO cache in the client. In a CDN/ 1083 ALTO interworking architecture where there's a few CDN component 1084 interacting with the ALTO server there are no scalability issues in 1085 maintaining state about clients in the ALTO server. 1087 5.1.6. Redirection 1089 When ALTO server receives an ECS request, it may not have the most 1090 appropriate topology information in order to accurately determine the 1091 ranking. In such case, the ALTO server, may want to adopt the 1092 following strategies: 1094 o Reply with available information (best effort). 1096 o Redirect the request to another ALTO server presumed to have 1097 better topology information (redirection). 1099 o Doing both (best effort and redirection). In this case, the reply 1100 message contains both the rankings and the indication of another 1101 ALTO server where more accurate rankings may be delivered. 1103 The decision process that is used to determine if redirection is 1104 necessary (and which mode to use) is out of the scope of this 1105 document. As an example, an ALTO server may decide to redirect any 1106 request having addresses that are located into a remote Autonomous 1107 System. In such case the redirection message includes the ALTO 1108 server to be used and that resides in the remote AS. Redirection 1109 implies communication between ALTO servers so to be able to signal 1110 their identity, location and type of visibility (AS number). 1112 5.1.7. Groups and Costs 1114 An automated ALTO implementation may use dynamic algorithms to 1115 aggregate network topology. However, it is often desirable to have a 1116 mechanism through which the network operator can control the level 1117 and details of network aggregation based on a set of requirements and 1118 constraints. IP/MPLS networks make use of a common mechanism to 1119 aggregate and group prefixes that is called BGP Communities. BGP is 1120 the protocol all SP networks use in order to exchange information 1121 about their prefix reachability. BGP Community us an attribute used 1122 to tag a prefix so to group prefixes based on mostly any criteria (as 1123 an example, most SP networks originate BGP prefixes with communities 1124 identifying the Point of Presence (PoP) where the prefix has been 1125 originated). 1127 The ALTO server may leverage the BGP information that is available in 1128 the SP network layer and compute group of prefixes. By policy, the 1129 ALTO server operator may decide an arbitrary cost to set between 1130 groups. Alternatively, there are algorithms that allows a dynamic 1131 computation of cost between groups. 1133 6. Advanced Features 1135 6.1. Cascading ALTO Servers 1137 The main assumptions of ALTO seems to be each ISP operates its own 1138 ALTO server independently, irrespectively of the ISP's situation. 1139 This may true for most envisioned deployments of ALTO but there are 1140 certain deployments that may have different settings. Figure 18 1141 shows such setting, were for example, a university network is 1142 connected to two upstream providers. ISP2 if the national research 1143 network and ISP1 is a commercial upstream provider to this university 1144 network. The university, as well as ISP1, are operating their own 1145 ALTO server. The ALTO clients, located on the peers will contact the 1146 ALTO server located at the university. 1148 +-----------+ 1149 | ISP1 | 1150 | ALTO | 1151 | Server | 1152 +----------=+ 1153 ,-------= ,------. 1154 ,-' =`-. ,-' `-. 1155 / Upstream= \ / Upstream \ 1156 ( ISP1 = ) ( ISP2 ) 1157 \ = / \ / 1158 `-. =,-' `-. ,-' 1159 `---+---= `+------' 1160 | = | 1161 | ======================= 1162 |,-------------. | = 1163 ,-+ `-+ +-----------+ 1164 ,' University `. |University | 1165 ( Network ) | ALTO | 1166 `. =======================| Server | 1167 `-= +-' +-----------+ 1168 =`+------------'| 1169 = | | 1170 +--------+-+ +-+--------+ 1171 | Peer1 | | PeerN | 1172 +----------+ +----------+ 1174 Figure 18: Cascaded ALTO Server 1176 In this setting all "destinations" useful for the peers within ISP2 1177 are free-of-charge for the peers located in the university network 1178 (i.e., they are preferred in the rating of the ALTO server). 1179 However, all traffic that is not towards ISP2 will be handled by the 1180 ISP1 upstream provider. Therefore, the ALTO server at the university 1181 has also to include the guidance given by the ISP1 ALTO server in its 1182 replies to the ALTO clients. This can be called cascaded ALTO 1183 servers. 1185 6.2. ALTO for IPv4 and IPv6 1187 TBD 1189 6.3. Monitoring ALTO 1191 In addition to providing configuration, an ISP providing ALTO may 1192 want to deploy a monitoring infrastructure to assess the benefits of 1193 ALTO and adjust its ALTO configuration according to the results of 1194 the monitoring. 1196 To construct an effective monitoring infrastructure, the ISP should 1197 (1) define the performance metrics to be monitored; (2) and identify 1198 and deploy data sources to collect data to compute the performance 1199 metrics. We discuss both below. 1201 [Editor's note: Is there a relationship to the IPPM working group at 1202 the IETF?] 1204 6.3.1. Monitoring Metrics Definition 1206 o Inter-domain ALTO-Integrated Application Traffic (Network metric): 1207 This metric includes total cross domain traffic generated by 1208 applications that utilize ALTO guidance. This metric evaluates 1209 the impacts of ALTO on the inbound and outbound traffic of a 1210 domain. 1212 o Total Inter-domain Traffic (Network metric): This is similar to 1213 the preceding but focuses on all of the traffic, ALTO aware or 1214 not. One possibility is that some of the reduction of interdomain 1215 traffic by ALTO aware applications may (XXX missing words?). This 1216 metric is always used with the preceding and the following 1217 metrics. 1219 o Intra-domain ALTO-Integrated Application Traffic (Network metric). 1220 (XXX description missing) 1222 o Network hop count (Network metric): This metric provides the 1223 average number of hops that traffic traverses inside a domain. 1224 ALTO may reduce not only traffic volume but also the hops. The 1225 metric can also indirectly reflect some application performance 1226 (e.g., latency). 1228 o Application download rate (Application metric): This metric 1229 measures application performance directly. Download means inbound 1230 traffic to one user. Global average means the average value of 1231 all users' download rates in one or more domains. 1233 o Application Client type audit(Application metric): this metric 1234 gives the audit of client types in ALTO service. The current 1235 types include fixed network client and mobile network client. 1237 6.3.2. Monitoring Data Sources 1239 The preceding metrics are derived from data sources. We identify 1240 three data sources. 1242 1. Application Log Server: Many application systems deploy Log 1243 Servers to collect data. 1245 2. P2P Clients: Some P2P applications may not have Log Servers. 1246 When available, P2P client logs can provide data. This is for 1247 P2P application 1249 3. OAM: Many ISPs deploy OAM systems to monitor IP layer traffic. 1250 An OAM provides traffic monitoring of every network device in its 1251 management area. It provides data such as link physical 1252 bandwidth and traffic volumes. 1254 6.3.3. Monitoring Structure 1256 As discussed in the preceding section, some data sources are from ISP 1257 while some others are from application. When there is a 1258 collaboration agreement between the ISP and an application, there can 1259 be an integrated monitoring system as shown in the figure below. In 1260 particular, an application developer may deploy Monitor Clients to 1261 communicate with Monitor Server of the ISP to transmit raw data from 1262 the Log Server or P2P clients of the application to the ISP. 1264 +------------------------------------------------+ 1265 | | 1266 | New Entities +--------------------------------------+ 1267 | | Service Provider | 1268 | | (P2P/CDN Operator etc)| 1269 | +-----------+ | +-----------+ | | 1270 | |ALTO Server|-------------|ALTO Client| | | 1271 | +-----------+ | +-----------+ | | 1272 | | | +----------+ | 1273 | | | |Log Server| | 1274 | | | +----------+ | 1275 | +--------------+ | +--------------+ | +----------+ | 1276 | |Monitor Server|----------|Monitor Client| | |P2P Client| | 1277 | +--------------+ | +--------------+ | +----------+ | 1278 | | | | | 1279 | +--------|--------+ +--------------------------------------+ 1280 +-|--------|--------|----------------------------+ 1281 | | | 1282 | | | 1283 | +---+ | 1284 | |OAM| | 1285 | +---+ | 1286 | ISP | 1287 ----------------- 1289 Figure 19: Monitoring Structure 1291 7. Known Limitations of ALTO 1293 This section describes some known limitations of ALTO in general or 1294 specific mechanisms in ALTO. 1296 7.1. Limitations of Map-based Approaches 1298 The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses, 1299 amongst others mechanism, so-called network maps. The network map 1300 approach uses Host Group Descriptors that group one or multiple 1301 subnetworks (i.e., IP prefixes) to a single Host Group Descriptor. A 1302 set of IP prefixes is called partition and the associated Host Group 1303 Descriptor is called partition ID. The "costs" between the various 1304 partition IDs is stored in a second map, the cost map. Map-based 1305 approaches are chosen as they lower the signaling load on the server, 1306 as the maps have only to be retrieved if they are changed. 1308 The main assumption for map-based approaches is that the information 1309 provided in these maps is static for a longer period of time, where 1310 this period of time refers to days, but not hours or even minutes. 1311 This assumption is fine, as long as the network operator does not 1312 change any parameter, e.g., routing within the network and to the 1313 upstream peers, IP address assignment stays stable (and thus the 1314 mapping to the partitions). However, there are several cases where 1315 this assumption is not valid, as: 1317 1. ISPs reallocate IPv4 subnets from time to time; 1319 2. ISPs reallocate IPv4 subnets on short notice; 1321 3. IP prefix blocks may be assigned to a single DSLAM which serves a 1322 variety of access networks. 1324 For 1): ISPs reallocate IPv4 subnets within their infrastructure from 1325 time to time, partly to ensure the efficient usage of IPv4 addresses 1326 (a scarce resource), and partly to enable efficient route tables 1327 within their network routers. The frequency of these "renumbering 1328 events" depend on the growth in number of subscribers and the 1329 availability of address space within the ISP. As a result, a 1330 subscriber's household device could retain an IPv4 address for as 1331 short as a few minutes, or for months at a time or even longer. 1333 Some folks have suggested that ISPs providing ALTO services could 1334 sub-divide their subscribers' devices into different IPv4 subnets 1335 (or certain IPv4 address ranges) based on the purchased service 1336 tier, as well as based on the location in the network topology. 1337 The problem is that this sub-allocation of IPv4 subnets tends to 1338 decrease the efficiency of IPv4 address allocation. A growing ISP 1339 that needs to maintain high efficiency of IPv4 address utilization 1340 may be reluctant to jeopardize their future acquisition of IPv4 1341 address space. 1343 However, this is not an issue for map-based approaches if changes are 1344 applied in the order of days. 1346 For 2): ISPs can use techniques, such as ODAP (XXX) that allow the 1347 reallocation of IP prefixes on very short notice, i.e., within 1348 minutes. An IP prefix that has no IP address assignment to a host 1349 anymore can be reallocate to areas where there is currently a high 1350 demand for IP addresses. 1352 For 3): In DSL-based access networks, IP prefixes are assigned to 1353 DSLAMs which are the first IP-hop in the access-network between the 1354 CPE and the Internet. The access-network between CPE and DSLAM 1355 (called aggregation network) can have varying characteristics (and 1356 thus associated costs), but still using the same IP prefix. For 1357 instance one IP addresses IP11 out of a IP prefix IP1 can be assigned 1358 to a VDSL (e.g., 2 MBit/s uplink) access-line while the subsequent IP 1359 address IP12 is assigned to a slow ADSL line (e.g., 128 kbit/s 1360 uplink). These IP addresses are assigned on a first come first 1361 served basis, i.e., the a single IP address out of the same IP prefix 1362 can change its associated costs quite fast. This may not be an issue 1363 with respect to the used upstream provider (thus the cross ISP 1364 traffic) but depending on the capacity of the aggregation-network 1365 this may raise to an issue. 1367 7.2. Limitiations of Non-Map-based Approaches 1369 The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses, 1370 amongst others mechanism, a mechanism called Endpoint Cost Service. 1371 ALTO clients can ask guidance for specific IP addresses to the ALTO 1372 server. However, asking for IP addresses, asking with long lists of 1373 IP addresses, and asking quite frequent may overload the ALTO server. 1374 The server has to rank each received IP address which causes load at 1375 the server. This may be amplified by the fact that not only a single 1376 ALTO client is asking for guidance, but a larger number of them. 1378 Caching of IP addresses at the ALTO client or the usage of the H12 1379 approach [I-D.kiesel-alto-h12] in conjunction with caching may lower 1380 the query load on the ALTO server. 1382 7.3. General Challenges 1384 An ALTO server stores information about preferences (e.g., a list of 1385 preferred autonomous systems, IP ranges, etc) and ALTO clients can 1386 retrieve these preferences. However, there are basically two 1387 different approaches on where the preferences are actually processed: 1389 1. The ALTO server has a list of preferences and clients can 1390 retrieve this list via the ALTO protocol. This preference list 1391 can be partially updated by the server. The actual processing of 1392 the data is done on the client and thus there is no data of the 1393 client's operation revealed to the ALTO server . 1395 2. The ALTO server has a list of preferences or preferences 1396 calculated during runtime and the ALTO client is sending 1397 information of its operation (e.g., a list of IP addresses) to 1398 the server. The server is using this operational information to 1399 determine its preferences and returns these preferences (e.g., a 1400 sorted list of the IP addresses) back to the ALTO client. 1402 Approach 1 (we call it H1) has the advantage (seen from the client) 1403 that all operational information stays within the client and is not 1404 revealed to the provider of the server. On the other hand, does 1405 approach 1 require that the provider of the ALTO server, i.e., the 1406 network operator, reveals information about its network structure 1407 (e.g., AS numbers, IP ranges, topology information in general) to the 1408 ALTO client. 1410 Approach 2 (we call it H2) has the advantage (seen from the operator) 1411 that all operational information stays with the ALTO server and is 1412 not revealed to the ALTO client. On the other hand, does approach 2 1413 require that the clients send their operational information to the 1414 server. 1416 Both approaches have their pros and cons and are extensively 1417 discussed on the ALTO mailing list. But there is basically a 1418 dilemma: Approach 1 is seen as the only working solution by peer-to- 1419 peer software vendors and approach 2 is seen as the only working by 1420 the network operators. But neither the software vendors nor the 1421 operators seem to willing to change their position. However, there 1422 is the need to get both sides on board, to come to a solution. 1424 8. Extensions to the ALTO Protocol 1426 8.1. Host Group Descriptors 1428 Host group descriptors are used in the ALTO client protocol to 1429 describe the location of a host in the network topology. The ALTO 1430 client protocol specification defines a basic set of host group 1431 descriptor types, which have to be supported by all implementations, 1432 and an extension procedure for adding new descriptor types . The 1433 following list gives an overview on further host group descriptor 1434 types that have been proposed in the past, or which are in use by 1435 ALTO-related prototype implementations. This list is not intended as 1436 normative text. Instead, the only purpose of the following list is 1437 to document the descriptor types that have been proposed so far, and 1438 to solicit further feedback and discussion: 1440 o Autonomous System (AS) number 1442 o Protocol-specific group identifiers, which expand to a set of IP 1443 address ranges (CIDR) and/or AS numbers. In one specific solution 1444 proposal, these are called Partition ID (PID). 1446 8.2. Rating Criteria 1448 Rating criteria are used in the ALTO client protocol to express 1449 topology- or connectivity-related properties, which are evaluated in 1450 order to generate the ALTO guidance. The ALTO client protocol 1451 specification defines a basic set of rating criteria, which have to 1452 be supported by all implementations, and an extension procedure for 1453 adding new criteria . The following list gives an overview on 1454 further rating criteria that have been proposed in the past, or which 1455 are in use by ALTO-related prototype implementations. This list is 1456 not intended as normative text. Instead, the only purpose of the 1457 following list is to document the rating criteria that have been 1458 proposed so far, and to solicit further feedback and discussion: 1460 8.2.1. Distance-related Rating Criteria 1462 o Relative topological distance: relative means that a larger 1463 numerical value means greater distance, but it is up to the ALTO 1464 service how to compute the values, and the ALTO client will not be 1465 informed about the nature of the information. One way of 1466 generating this kind of information MAY be counting AS hops, but 1467 when querying this parameter, the ALTO client MUST NOT assume that 1468 the numbers actually are AS hops. 1470 o Absolute topological distance, expressed in the number of 1471 traversed autonomous systems (AS). 1473 o Absolute topological distance, expressed in the number of router 1474 hops (i.e., how much the TTL value of an IP packet will be 1475 decreased during transit). 1477 o Absolute physical distance, based on knowledge of the approximate 1478 geolocation (continent, country) of an IP address. 1480 8.2.2. Charging-related Rating Criteria 1482 o Traffic volume caps, in case the Internet access of the resource 1483 consumer is not charged by "flat rate". For each candidate 1484 resource provider, the ALTO service could indicate the amount of 1485 data that may be transferred from/to this resource provider until 1486 a given point in time, and how much of this amount has already 1487 been consumed. Furthermore, it would have to be indicated how 1488 excess traffic would be handled (e.g., blocked, throttled, or 1489 charged separately at an indicated price). The interaction of 1490 several applications running on a host, out of which some use this 1491 criterion while others don't, as well as the evaluation of this 1492 criterion in resource directories, which issue ALTO queries on 1493 behalf of other peers, are for further study. 1495 8.2.3. Performance-related Rating Criteria 1497 The following rating criteria are subject to the remarks below. 1499 o The minimum achievable throughput between the resource consumer 1500 and the candidate resource provider, which is considered useful by 1501 the application (only in ALTO queries), or 1503 o An arbitrary upper bound for the throughput from/to the candidate 1504 resource provider (only in ALTO responses). This may be, but is 1505 not necessarily the provisioned access bandwidth of the candidate 1506 resource provider. 1508 o The maximum round-trip time (RTT) between resource consumer and 1509 the candidate resource provider, which is acceptable for the 1510 application for useful communication with the candidate resource 1511 provider (only in ALTO queries), or 1513 o An arbitrary lower bound for the RTT between resource consumer and 1514 the candidate resource provider (only in ALTO responses). This 1515 may be, for example, based on measurements of the propagation 1516 delay in a completely unloaded network. 1518 The ALTO client MUST be aware, that with high probability, the actual 1519 performance values differ significantly from these upper and lower 1520 bounds. In particular, an ALTO client MUST NOT consider the "upper 1521 bound for throughput" parameter as a permission to send data at the 1522 indicated rate without using congestion control mechanisms. 1524 The discrepancies are due to various reasons, including, but not 1525 limited to the facts that 1527 o the ALTO service is not an admission control system 1529 o the ALTO service may not know the instantaneous congestion status 1530 of the network 1532 o the ALTO service may not know all link bandwidths, i.e., where the 1533 bottleneck really is, and there may be shared bottlenecks 1535 o the ALTO service may not know whether the candidate peer itself is 1536 overloaded 1538 o the ALTO service may not know whether the candidate peer throttles 1539 the bandwidth it devotes for the considered application 1541 o the ALTO service may not know whether the candidate peer will 1542 throttle the data it sends to us (e.g., because of some fairness 1543 algorithm, such as tit-for-tat) 1545 Because of these inaccuracies and the lack of complete, instantaneous 1546 state information, which are inherent to the ALTO service, the 1547 application must use other mechanisms (such as passive measurements 1548 on actual data transmissions) to assess the currently achievable 1549 throughput, and it MUST use appropriate congestion control mechanisms 1550 in order to avoid a congestion collapse. Nevertheless, these rating 1551 criteria may provide a useful shortcut for quickly excluding 1552 candidate resource providers from such probing, if it is known in 1553 advance that connectivity is in any case worse than what is 1554 considered the minimum useful value by the respective application. 1556 8.2.4. Inappropriate Rating Criteria 1558 Rating criteria that SHOULD NOT be defined for and used by the ALTO 1559 service include: 1561 o Performance metrics that are closely related to the instantaneous 1562 congestion status. The definition of alternate approaches for 1563 congestion control is explicitly out of the scope of ALTO. 1564 Instead, other appropriate means, such as using TCP based 1565 transport, have to be used to avoid congestion. 1567 9. API between ALTO Client and Application 1569 This sections gives some informational guidance on how the interface 1570 between the actual application using the ALTO guidance and the ALTO 1571 client can look like. 1573 This is still TBD. 1575 10. Security Considerations 1577 The ALTO protocol itself, as well as, the ALTO client and server 1578 raise new security issues beyond the one mentioned in 1579 [I-D.ietf-alto-protocol] and issues related to message transport over 1580 the Internet. For instance, Denial of Service (DoS) is of interest 1581 for the ALTO server and also for the ALTO client. A server can get 1582 overloaded if too many TCP requests hit the server, or if the query 1583 load of the server surpasses the maximum computing capacity. An ALTO 1584 client can get overloaded if the responses from the sever are, either 1585 intentionally or due to an implementation mistake, too large to be 1586 handled by that particular client. 1588 10.1. Information Leakage from the ALTO Server 1590 The ALTO server will be provisioned with information about the owning 1591 ISP's network and very likely also with information about neighboring 1592 ISPs. This information (e.g., network topology, business relations, 1593 etc) is consider to be confidential to the ISP and must not be 1594 revealed. 1596 The ALTO server will naturally reveal parts of that information in 1597 small doses to peers, as the guidance given will depend on the above 1598 mentioned information. This is seen beneficial for both parties, 1599 i.e., the ISP's and the peer's. However, there is the chance that 1600 one or multiple peers are querying an ALTO server with the goal to 1601 gather information about network topology or any other data 1602 considered confidential or at least sensitive. It is unclear whether 1603 this is a real technical security risk or whether this is more a 1604 perceived security risk. 1606 10.2. ALTO Server Access 1608 Depending on the use case of ALTO, several access restrictions to an 1609 ALTO server may or may not apply. For an ALTO server that is solely 1610 accessible by peers from the ISP network (as shown in Figure 12), for 1611 instance, the source IP address can be used to grant only access from 1612 that ISP network to the server. This will "limit" the number of 1613 peers able to attack the server to the user's of the ISP (however, 1614 including botnet computers). 1616 On the other hand, if the ALTO server has to be accessible by parties 1617 not located in the ISP's network (see Figure Figure 11), e.g., by a 1618 third-party tracker or by a CDN system outside the ISP's network, the 1619 access restrictions have to be more loose. In the extreme case, 1620 i.e., no access restrictions, each and every host in the Internet can 1621 access the ALTO server. This might no the intention of the ISP, as 1622 the server is not only subject to more possible attacks, but also on 1623 the load imposed to the server, i.e., possibly more ALTO clients to 1624 serve and thus more work load. 1626 10.3. Faking ALTO Guidance 1628 It has not yet been investigated how a faked or wrong ALTO guidance 1629 by an ALTO server can impact the operation of the network and also 1630 the peers. 1632 Here is a list of examples how the ALTO guidance could be faked and 1633 what possible consequences may arise: 1635 Sorting An attacker could change to sorting order of the ALTO 1636 guidance (given that the order is of importance, otherwise the 1637 ranking mechanism is of interest), i.e., declaring peers located 1638 outside the ISP as peers to be preferred. This will not pose a 1639 big risk to the network or peers, as it would mimic the "regular" 1640 peer operation without traffic localization, apart from the 1641 communication/processing overhead for ALTO. However, it could 1642 mean that ALTO is reaching the opposite goal of shuffling more 1643 data across ISP boundaries, incurring more costs for the ISP. 1645 Preference of a single peer A single IP address (thus a peer) could 1646 be marked as to be preferred all over other peers. This peer can 1647 be located within the local ISP or also in other parts of the 1648 Internet (e.g., a web server). This could lead to the case that 1649 quite a number of peers to trying to contact this IP address, 1650 possibly causing a Denial of Service (DoS) attack. 1652 This section is solely giving a first shot on security issues related 1653 to ALTO deployments. 1655 11. Conclusion 1657 This is the first version of the deployment considerations and for 1658 sure the considerations are yet incomplete and imprecise. 1660 12. References 1662 12.1. Normative References 1664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1665 Requirement Levels", BCP 14, RFC 2119, March 1997. 1667 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 1668 Content Network (CN) Request-Routing Mechanisms", 1669 RFC 3568, July 2003. 1671 12.2. Informative References 1673 [I-D.ietf-alto-protocol] 1674 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 1675 draft-ietf-alto-protocol-13 (work in progress), 1676 September 2012. 1678 [I-D.ietf-alto-server-discovery] 1679 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 1680 S. Yongchao, "ALTO Server Discovery", 1681 draft-ietf-alto-server-discovery-07 (work in progress), 1682 January 2013. 1684 [I-D.kamei-p2p-experiments-japan] 1685 Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "ALTO- 1686 Like Activities and Experiments in P2P Network Experiment 1687 Council", draft-kamei-p2p-experiments-japan-09 (work in 1688 progress), October 2012. 1690 [I-D.kiesel-alto-h12] 1691 Kiesel, S. and M. Stiemerling, "ALTO H12", 1692 draft-kiesel-alto-h12-02 (work in progress), March 2010. 1694 [I-D.lee-alto-chinatelecom-trial] 1695 Li, K. and G. Jian, "ALTO and DECADE service trial within 1696 China Telecom", draft-lee-alto-chinatelecom-trial-04 (work 1697 in progress), March 2012. 1699 [I-D.penno-alto-cdn] 1700 Penno, R., Medved, J., Alimi, R., Yang, R., and S. 1701 Previdi, "ALTO and Content Delivery Networks", 1702 draft-penno-alto-cdn-03 (work in progress), March 2011. 1704 [I-D.vandergaast-edns-client-ip] 1705 Contavalli, C., Gaast, W., Leach, S., and D. Rodden, 1706 "Client IP information in DNS requests", 1707 draft-vandergaast-edns-client-ip-01 (work in progress), 1708 May 2010. 1710 [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and 1711 Y. Yang, "Comcast's ISP Experiences in a Proactive Network 1712 Provider Participation for P2P (P4P) Technical Trial", 1713 RFC 5632, September 2009. 1715 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1716 Optimization (ALTO) Problem Statement", RFC 5693, 1717 October 2009. 1719 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 1720 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 1721 Requirements", RFC 6708, September 2012. 1723 Appendix A. Contributors List and Acknowledgments 1725 This memo is the result of contributions made by several people, such 1726 as: 1728 o Xianghue Sun, Lee Kai, and Richard Yang contributed Section 3 and 1729 Section 6.3. 1731 o Stefano Previdi contributed Section Section 5 on "Using ALTO for 1732 CDNs". 1734 Martin Stiemerling is partially supported by the CHANGE project ( 1735 http://www.change-project.eu), a research project supported by the 1736 European Commission under its 7th Framework Program (contract no. 1737 257422). The views and conclusions contained herein are those of the 1738 authors and should not be interpreted as necessarily representing the 1739 official policies or endorsements, either expressed or implied, of 1740 the CHANGE project or the European Commission. 1742 Authors' Addresses 1744 Martin Stiemerling (editor) 1745 NEC Laboratories Europe 1746 Kurfuerstenanlage 36 1747 Heidelberg 69115 1748 Germany 1750 Phone: +49 6221 4342 113 1751 Fax: +49 6221 4342 155 1752 Email: martin.stiemerling@neclab.eu 1753 URI: http://ietf.stiemerling.org 1755 Sebastian Kiesel (editor) 1756 University of Stuttgart, Computing Center 1757 Allmandring 30 1758 Stuttgart 70550 1759 Germany 1761 Email: ietf-alto@skiesel.de 1763 Stefano Previdi 1764 Cisco Systems, Inc. 1765 Via Del Serafico 200 1766 Rome 00191 1767 Italy 1769 Email: sprevidi@cisco.com