idnits 2.17.1 draft-yang-alto-architecture-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 4, 2009) is 5530 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-marocco-alto-problem-statement-04 == Outdated reference: A later version (-02) exists of draft-kiesel-alto-reqs-01 -- No information found for draft-wang-p4p-spec - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Working Group YR. Yang, Ed. 3 Internet-Draft Yale University 4 Intended status: Informational D. Pasko 5 Expires: September 5, 2009 Verizon 6 L. Popkin 7 Pando Networks 8 R. Penno 9 Juniper 10 S. Shalunov 11 BitTorrent 12 March 4, 2009 14 An Architecture of ALTO for P2P Applications 15 draft-yang-alto-architecture-00.txt 17 Status of This Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 5, 2009. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 ALTO enables Internet Service Providers (ISPs) and network 54 application software distributors to work jointly and cooperatively 55 to reduce network resource consumption and to improve application 56 performance. In this document, we specify an architecture for 57 integrating ALTO into peer-to-peer (P2P) applications. 59 Table of Contents 61 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.4. Comparisons with Alternatives . . . . . . . . . . . . . . 4 67 3. Architectural Model . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1.1. My-Internet View . . . . . . . . . . . . . . . . . . . 4 70 3.1.2. ALTO Cost Type . . . . . . . . . . . . . . . . . . . . 4 71 3.1.3. Hosting ALTO Server . . . . . . . . . . . . . . . . . 5 72 3.1.4. Location Grouping . . . . . . . . . . . . . . . . . . 5 73 3.2. Basic Functional Components . . . . . . . . . . . . . . . 7 74 3.2.1. ALTO Query/Response Protocol . . . . . . . . . . . . . 8 75 3.2.2. ALTO Service Discovery . . . . . . . . . . . . . . . . 8 76 3.3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.3.1. Redistribution and Caching of ALTO Info . . . . . . . 9 78 3.3.2. ALTO Effectiveness Monitoring . . . . . . . . . . . . 9 79 4. Example Functional Components Instantiations . . . . . . . . . 9 80 4.1. Tracker-based Peer Selection using ALTO . . . . . . . . . 10 81 4.2. Client Peer Selection using ALTO . . . . . . . . . . . . . 10 82 5. P2P Application ALTO Integration Guidelines . . . . . . . . . 10 83 5.1. Peer Selection Guidelines . . . . . . . . . . . . . . . . 10 84 5.2. Interoperability with Non-ALTO Clients . . . . . . . . . . 11 85 6. ALTO Service Discovery Guidelines . . . . . . . . . . . . . . 11 86 6.1. Delegation . . . . . . . . . . . . . . . . . . . . . . . . 11 87 6.2. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 6.3. Load Balancing and Robustness . . . . . . . . . . . . . . 11 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 92 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 93 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 12 94 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 96 1. Requirements Notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. Introduction 104 2.1. Overview 106 ALTO is a service to allow Internet service providers (ISPs) and 107 network applications to work more cooperatively. Since in general 108 peer-to-peer applications generate large amounts of Internet traffic 109 and many of these produce traffic patterns that are network- 110 oblivious, it is important to provide such applications with more 111 information so that they can effectively utilize their communication 112 flexibility to perform better-than-random peer selection, which can 113 reduce network resource consumption and improve application 114 performance. 116 Recently, multiple schemes have been proposed, including ALTO Info 117 Export [Info-Export], P4P [P4P-framework], and PROXIDOR [PROXIDOR]. 118 These schemes represent different points at the solution spectrum. 120 This document presents a unifying architecture of how ALTO can be 121 integrated into large P2P applications such as those based on 122 BitTorrent (e.g., BitTorrent and PPLive). This class of applications 123 share many common features to allow a unified study of architecture. 125 The objective of this document is to complement the Problem Statement 126 [ALTO-Problem] and the Requirements [ALTO-Reqs] documents to identify 127 the essential functional components in the architecture. Note that 128 the architecture presented in this document serves an informative 129 purpose only. It provides a conceptual framework for more structured 130 design and discussions. 132 2.2. Terminology 134 We use the following terms defined in [ALTO-Problem]: 136 Application, Overlay Network, Peer, Resource, Resource Identifier, 137 Resource Provider, Resource Consumer, Resource Directory, Transport 138 Address, Host Location Attribute, ALTO Service, ALTO Server, ALTO 139 Client, ALTO Query, ALTO Reply, ALTO Transaction, Local Traffic, 140 Peering Traffic, Transit Traffic. 142 2.3. Requirements 144 The architecture to be presented is guided by the following key 145 design requirements: 147 o The architecture is extensible so that ALTO information can be 148 used by both P2P Peers and P2P Application trackers (e.g., a 149 BitTorrent tracker uses ALTO for initial peer selection). 150 Tracker-based peer selection can be beneficial given the global 151 knowledge of a tracker about a P2P Application. However, since a 152 P2P tracker may manage a large number of Peers, ALTO should avoid 153 substantial workload and redundancy on the tracker. 155 o Each ISP or its delegate can configure the ALTO Server that 156 provides the information about the ISP's network. Each ISP can 157 determine the level of detail that it wishes to expose. It 158 applies any desired aggregation and transformation mechanisms. 159 Information from ALTO Servers can be "anonymized" or access- 160 controlled to protect the ISP's topology and business policies. 161 Although multiple ISPs can interact and negotiate with respect to 162 the information provided by their ALTO Servers, it is outside the 163 scope of this architecture. 165 2.4. Comparisons with Alternatives 167 To be added. 169 3. Architectural Model 171 3.1. Basic Concepts 173 3.1.1. My-Internet View 175 The basic architecture we present is based on a simple model that 176 each ALTO Server defines a "my-Internet" view, which consists of a 177 set of network locations identifiable by Host Location Attributes, 178 and generic costs among network locations. An ALTO Service provides 179 its service based on its my-Internet view. 181 3.1.2. ALTO Cost Type 183 An ALTO server may allow multiple types of generic costs to be 184 defined between each pair of network locations. Example types 185 include hop-count, air-mile, and routing-cost. We refer to each type 186 as an ALTO Cost Type. 188 3.1.3. Hosting ALTO Server 190 Given a Resource Consumer p and a given type of ALTO Cost, an ALTO 191 Client identifies a Hosting ALTO Server using ALTO Service Discovery. 192 Network efficiency for p's behavior is considered from the my- 193 Internet view of the Hosting ALTO Server of p. 195 3.1.4. Location Grouping 197 In this architecture, we introduce Location Grouping in ALTO Queries 198 and Responses for scalability and privacy. 200 Specifically, an ALTO Query specifies a set of locations on the my- 201 Internet view representing Resource Consumers, and a set of locations 202 on the my-Internet view representing potential Resource Providers. 203 The ALTO Response reveals network information related with these 204 network locations. 206 We distinguish two types of location grouping: Source (Resource 207 Consumer) Grouping and Destination (Resource Provider) Grouping. 209 3.1.4.1. Source Grouping 211 Without Source Grouping, each ALTO Query is from the vantage point of 212 a specific Resource Consumer on the my-Internet view. Consequently, 213 the number of ALTO Queries to be handled (both by ALTO Servers and 214 ALTO Clients) will grow with the number of Peers, which can be large. 215 This can be particularly challenging for tracker-based systems, where 216 a tracker manages a large number of peers and it is the tracker who 217 uses ALTO to make initial peer selections. 219 One can identify settings where fine-grained queries for individual 220 IP addresses are necessary, and thus should be supported. 222 On the other hand, for many ISPs and in particular in the setting of 223 P2P, network information for each individual IP address may not be 224 necessary or too fine-grained. Instead, a set of network locations 225 may have similar costs to other network locations. Thus, an ISP, 226 through its ALTO Server, may specify equivalent classes of network 227 locations containing Resource Consumers. Each such class is called a 228 Source Grouping. 230 By defining Source Grouping, we improve both scalability and privacy: 232 o Scalability: The number of ALTO Queries grow with the number of 233 Source Groupings. The state at a tracker who uses ALTO to make 234 initial peer selection grows with the number of Source Groupings 235 instead of the number of Peers. It also makes it possible for 236 Peers to share ALTO information (e.g., redistribution using P2P), 237 in both tracker-based and tracker-less P2P Applications. 239 o Privacy: By issuing ALTO queries for Source Groupings, it avoids 240 revealing individual Peer information. 242 3.1.4.2. Destination Grouping 244 The network information to a set of network locations as Resource 245 Providers may be similar. For example, although there are tens of 246 thousands of Autonomous Systems (ASes), the routing costs of an ISP 247 to these ASes may be quite coarse-grained (e.g., according to the 248 business relationship of the first hop BGP peer). Thus, an ISP, 249 through its ALTO Server, may specify equivalent classes of 250 destination network locations. Each such class is a Destination 251 Grouping. Destination Grouping can reduce redundancy, improve 252 scalability, and can help to protect Peer privacy. 254 3.1.4.3. Grouping Levels 256 The level of grouping can span a whole spectrum: individual IP 257 address, a subnet, a set of subnets, a point of presence (PoP), an 258 Internet exchange point, an autonomous system (AS), a set of 259 autonomous systems (e.g., those with the same next-hop AS, those 260 reachable through provider ASes, or those with the same BGP AS_PATH 261 length), or some other set defined by a common set of properties. 263 Although some of the preceding groupings can be naturally expressed 264 using the current Internet addressing scheme (IP prefix, ASN), others 265 (e.g., PoP, those reachable through provider ASes) are not. 267 In this architecture, we adopt a generic approach. Each grouping is 268 identified by a Network Grouping Identifier to allow flexibility, 269 reuse and reducing redundancy. A Grouping Identifier can be 270 considered as a Host Location Attribute. 272 3.1.4.4. Grouping Examples 274 Table 1 illustrates how the three approaches aforementioned in the 275 Introduction use Location Grouping. The column "Source Grouping" 276 denotes the levels of Source Groupings supported (i.e, how an ALTO 277 Client specifies a Resource Consumer), the column "Destination Query" 278 denotes how an ALTO Client specifies the Resource Providers 279 (candidate Peers), and the column "Destination Grouping" denotes the 280 levels of Destination Groupings supported. 282 +----------+----------------------+-----------------+---------------+ 283 | Approach | Source Grouping | Destination | Destination | 284 | | | Query | Grouping | 285 +----------+----------------------+-----------------+---------------+ 286 | Info | Per IP address Query | Does not | CIDR; ASN | 287 | Export | | specify; assume | | 288 | | | whole address | | 289 | | | space | | 290 +----------+----------------------+-----------------+---------------+ 291 | PROXIDOR | Per [Src IP, list of | List of IP | IP address; | 292 | | Dst IP] Query; May | addresses; | Mentioned | 293 | | extend to use | Mentioned | possibility | 294 | | CIDR/ASN to replace | possibility of | of using | 295 | | IP | using CIDR/ASN | CIDR/ASN in | 296 | | | in place of IP | place of IP | 297 +----------+----------------------+-----------------+---------------+ 298 | P4P | One query for each | List of | Same as | 299 | | Source Grouping; | CIDR/ASN/PIDs | Source | 300 | | Source Grouping can | | Grouping | 301 | | be CIDR, ASN, or PID | | | 302 | | which is a set of | | | 303 | | CIDR/ASN. | | | 304 +----------+----------------------+-----------------+---------------+ 306 Table 1: Grouping Levels Used in ALTO Info Export, P4P, and PROXIDOR. 308 3.2. Basic Functional Components 310 Given the preceding key concepts, we now introduce the basic 311 functional components. Figure 1 shows the main functional components 312 in the basic architecture: 314 .----------. .-----------. 315 | ALTO | ALTO Query/Response | ALTO | 316 | Server | -------------------- | Client | 317 `----------' `-----------' 318 / 319 ALTO SD Query/Response / 320 / 321 .............. 322 : ALTO Service : 323 : Discovery : 324 `..............' 326 Figure 1: Basic ALTO Architecture. 328 o ALTO Query/Response: We refer to an ALTO Query and its 329 corresponding ALTO Response as an ALTO Transaction. The 330 information conveyed in ALTO Transactions is referred to as ALTO 331 Information. 333 o ALTO Service Discovery: Although it is possible to use manual 334 configuration to avoid this component, for large-scale deployment, 335 service discovery is necessary. 337 3.2.1. ALTO Query/Response Protocol 339 Specifically, different types of ALTO Queries can be constructed 340 depending on the information needed by the client. In its most 341 generic form, an ALTO query specifies (1) a set of Host Location 342 Attributes (Network Grouping Identifiers) representing Resource 343 Consumers, (2) a set of Host Location Attributes (Network Grouping 344 Identifiers) representing potential Resource Providers, and (3) a 345 desirable ALTO Cost Type. 347 An ALTO Response includes the values of the costs from the Resource 348 Consumers to the Resource Providers. 350 The returned information may also be in a transformed format. For 351 example, instead of the exact values, they may be rankings derived 352 from the cost values. The response will be used for making peer 353 selection. 355 3.2.2. ALTO Service Discovery 357 3.3. Extensions 359 The Basic Architecture provides interoperability, but lacks 360 components for (1) improving scalability, (2) using multiple 361 information sources, and (3) handling issues that can arise when 362 networks and P2P applications operate autonomously. Although the 363 ALTO Working Group may not pursue these components initially, it is 364 important to identify the related issues when defining the core 365 components defined in the Basic Architecture. 367 Figure 2 shows additional functional components. In particular, 368 ultimately, P2P applications make peer selection decisions based on 369 multiple sources of information, including not only ALTO information, 370 but also application state (e.g., distribution of super nodes, seeds, 371 and down loaders), and other sources of information such as probed 372 network information or shared underlay information. 374 .................. .............. 375 : ALTO Effective. : : Other : 376 : Monitoring :----: Information : 377 : : : Sources : 378 `..................' `..............' 379 | \ | 380 ALTO Info | \ | 381 | \ | 382 .----------. ALTO .-----------. ALTO ................ 383 | ALTO | Query/Response | ALTO | Info : Peer Selection : 384 | Server | ---------------| Client | ---> : Logic : 385 `----------' `-----------' `................' 386 / \ 387 ALTO SD Query/Response / \ 388 / \ 389 .............. .................. 390 : ALTO Service : : ALTO Information : 391 : Discovery : : Redistribution : 392 `..............' `..................' 394 Figure 2: ALTO Architecture Extension. 396 3.3.1. Redistribution and Caching of ALTO Info 398 Redistribution and Caching of ALTO Information: Large-scale 399 deployment of P2P applications may generate a large number of ALTO 400 Transactions. Thus, mechanisms for the caching (e.g., leveraging 401 HTTP caches [P4P-spec]) and redistribution (e.g., using P2P) of ALTO 402 Information are necessary to avoid ALTO becoming a system bottleneck 403 and to reduce ISP deployment costs. 405 In particular, if redistribution is allowed, then the ALTO Request/ 406 Response protocol may include mechanism to allow ease of 407 redistribution and validation of redistributed ALTO Information. 409 3.3.2. ALTO Effectiveness Monitoring 411 ALTO Effectiveness Monitoring: Applications evaluate effectiveness of 412 ALTO information, and the effectiveness is used in Peer Selection. 413 It is possible that networks may also want to monitor the effects of 414 its provided ALTO information. 416 4. Example Functional Components Instantiations 418 The preceding section gives basic functional components. In this 419 section, we give instantiations of the architecture for multiple 420 application scenarios. 422 4.1. Tracker-based Peer Selection using ALTO 424 In this setting, the application tracker (Resource Directory) keeps 425 track of Peers in a torrent. There is an ALTO Client embedded in the 426 application tracker. The ALTO Client queries the ALTO Servers of the 427 Peers in the torrent to obtain their my-Internet views. Then the 428 application tracker conducts peer selection. 430 There can be an alternative instantiation, in which a third party 431 provides an ALTO Client (e.g., application optimization engine 432 [P4P-SIGCOMM08], [P4P-framework]). The application tracker sends 433 application state to the third party, who issues ALTO Queries and 434 computes peer selection guidance for the application tracker. 436 4.2. Client Peer Selection using ALTO 438 In this setting, a Peer uses ALTO when conducting peer selection 439 (i.e., selecting among the known peers those that it preferentially 440 connects to). There are several settings that this may happen: 442 o There does not exist a tracker. The Peers discover each other 443 using mechanisms such as DHT. 445 o There is a tracker but the tracker does not support ALTO (yet). 447 o Even though there is a tracker and the tracker applies ALTO when 448 conducting initial peer selection, the Peer applies ALTO when 449 selecting peers as it learns additional peers such as those from 450 Peer Exchange. 452 There are at least two types of instantiations of ALTO Clients in 453 this setting: In the first case, an ALTO Client is embedded in the 454 BitTorrent Client; in the second case, the ALTO Client is implemented 455 as part of the operating system. 457 In either case, the ALTO Client discovers the ALTO Server of the 458 Internet Service Provider of the Peer. Then the ALTO Client obtains 459 the my-Internet view of the ISP to help with peer selection. 461 5. P2P Application ALTO Integration Guidelines 463 5.1. Peer Selection Guidelines 465 Multiple examples of using ALTO Information have been proposed (e.g., 466 the usage examples in [Info-Export], the Application Optimization 467 Engine in [P4P-framework], and the example usages in [PROXIDOR]. 468 Although it is unlikely that we can enforce Applications behaviors, 469 development of guidelines for Application peer selection can be 470 beneficial, in an organization such as the P4P Working Group. 472 5.2. Interoperability with Non-ALTO Clients 474 To be added. 476 6. ALTO Service Discovery Guidelines 478 Key issues in ALTO Service Discovery are the following: 480 6.1. Delegation 482 6.2. NAT 484 6.3. Load Balancing and Robustness 486 7. Security Considerations 488 There are security considerations from the perspectives of both ISPs 489 and P2P applications. See [ALTO-Problem] and [ALTO-Reqs] for 490 discussions. 492 8. References 494 8.1. Normative References 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, March 1997. 499 8.2. Informative References 501 [ALTO-Problem] Seedorf, J. and E. Burger, "Application-Layer 502 Traffic Optimization (ALTO) Problem Statement", 503 draft-marocco-alto-problem-statement-04 (work in 504 progress) 2009. 506 [ALTO-Reqs] S. Kiesel, L. Popkin, S. Previdi, R. Woundy, and 507 YR. Yang, "Application-Layer Traffic Optimization 508 (ALTO) Requirements", draft-kiesel-alto-reqs-01 509 (work in progress) 2008. 511 [Info-Export] S. Shalunov, R. Penno, and R. Woundy, "ALTO 512 Information Export Service", 513 draft-shalunov-alto-infoexport-00 (work in progress) 514 2008. 516 [P4P-SIGCOMM08] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. 517 Silberschatz., "P4P: Provider Portal for (P2P) 518 Applications", In SIGCOMM 2008. 520 [P4P-framework] R. Alimi, D. Pasko, L. Popkin, Y. Wang, and YR. 521 Yang., "P4P: Provider Portal for (P2P) 522 Applications", draft-p4p-framework-00 (work in 523 Progress) 2008. 525 [P4P-spec] Y. Wang, R. Alimi, D. Pasko, L. Popkin, and YR. 526 Yang., "P4P Protocol Spec", draft-wang-p4p-spec-00 527 (work in Progress) 2009. 529 [PROXIDOR] O. Akonjang, A. Feldmann, S. Previdi, B. Davie, and 530 D. Saucez, "The PROXIDOR Service", 531 draft-akonjang-alto-proxidor-00.txt (work in 532 progress) 2009. 534 Appendix A. Contributors 536 Additional contributors: 538 o Richard Alimi, Yale 540 o Satish Raghunath, Juniper 542 o Richard Woundy, Comcast 544 o Yu-Shun Wang, Microsoft 546 Appendix B. Acknowledgments 548 The authors would like to thank the members of the p4p/alto/p2pi 549 mailing lists for their insights. The concept of my-Internet view is 550 from Emilio Sepulveda of Telefonica. The authors benefited from 551 multiple discussions with Stefano Previdi and Anja Feldmann. 553 Authors' Addresses 555 Y. Richard Yang (editor) 556 Yale University 558 EMail: yry@cs.yale.edu 560 D. Pasko 561 Verizon 563 EMail: pasko@verizon.com 564 L. Popkin 565 Pando Networks 567 EMail: laird@pando.com 569 Reinaldo Penno 570 Juniper 572 EMail: rpenno@juniper.net 574 Stanislav Shalunov 575 BitTorrent 577 EMail: shalunov@bittorrent.com