idnits 2.17.1 draft-p4p-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1276. 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 are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 23 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document date (November 17, 2008) is 5638 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Alimi 3 Internet-Draft Yale University 4 Intended status: Informational D. Pasko 5 Expires: May 21, 2009 Verizon 6 L. Popkin 7 Pando Networks, Inc. 8 Y. Wang 9 Y. Yang, Ed. 10 Yale University 11 November 17, 2008 13 P4P: Provider Portal for P2P Applications 14 draft-p4p-framework-00.txt 16 Status of This Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 21, 2009. 41 Abstract 43 P4P is a framework that enables Internet Service Providers (ISPs) and 44 network application software distributors to work jointly and 45 cooperatively to optimize application communications. The goals of 46 this cooperation are to reduce network resource consumption and to 47 accelerate network applications. In this document, we specify how 48 P4P allows ISPs to provide network guidance to applications, allowing 49 clients to exchange data more effectively. The applications we focus 50 on are those that can have a choice in connection patterns, in 51 particular peer-to-peer (P2P) applications. 53 Table of Contents 55 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. P4P Terminology and Entities . . . . . . . . . . . . . . . . . 5 58 4. P4P Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 8 59 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.2. Location Portal Service . . . . . . . . . . . . . . . . . 8 61 4.2.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . 8 62 4.2.2. Querying Entities . . . . . . . . . . . . . . . . . . 9 63 4.3. pDistance Portal Service . . . . . . . . . . . . . . . . . 9 64 4.3.1. Interface . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Example Usage of P4P Interfaces . . . . . . . . . . . . . . . 10 66 5.1. Example E1: Querying for Individual Client Addresses . . . 10 67 5.2. Example E2: Aggregated Query Using PIDs . . . . . . . . . 10 68 5.3. Example E3: Utilizing an Application Optimization 69 Service . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 6. Extended Usage of PIDs . . . . . . . . . . . . . . . . . . . . 13 71 6.1. PID Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 6.1.1. Aggregation PIDs . . . . . . . . . . . . . . . . . . . 13 73 6.1.2. Resource PIDs . . . . . . . . . . . . . . . . . . . . 13 74 6.2. Example X1: Using PIDs to Identify Caches . . . . . . . . 14 75 6.3. Example X2: Using PIDs for ISP AVOID/PREFER . . . . . . . 14 76 7. Portal Server Discovery . . . . . . . . . . . . . . . . . . . 15 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 8.1. Security Considerations for ISPs . . . . . . . . . . . . . 15 79 8.2. Security Considerations for P2P Applications . . . . . . . 16 80 9. Discussion and Extensions . . . . . . . . . . . . . . . . . . 17 81 9.1. ISP Information . . . . . . . . . . . . . . . . . . . . . 17 82 9.1.1. pDistance Semantics and Calculation . . . . . . . . . 17 83 9.1.2. pDistance Direction . . . . . . . . . . . . . . . . . 18 84 9.1.3. Aggregation PIDs . . . . . . . . . . . . . . . . . . . 18 85 9.1.4. Hierarchical PIDs . . . . . . . . . . . . . . . . . . 19 86 9.1.5. PID Attributes . . . . . . . . . . . . . . . . . . . . 19 87 9.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 20 88 9.2.1. Caching P4P Information . . . . . . . . . . . . . . . 20 89 9.2.2. Client PID Retrieval . . . . . . . . . . . . . . . . . 20 90 9.2.3. Global PIDs and my-Internet View . . . . . . . . . . . 20 91 9.2.4. Granularity of Information . . . . . . . . . . . . . . 21 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 95 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 22 96 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 97 Appendix C. P4P Protocol Example . . . . . . . . . . . . . . . . 23 98 C.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 C.2. ISP Portal Service Configuration . . . . . . . . . . . . . 23 100 C.3. Tracker-based P2P Application . . . . . . . . . . . . . . 24 101 C.4. Tracker-less P2P Application . . . . . . . . . . . . . . . 25 103 1. Requirements Notation 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Introduction 111 P4P, which stands for provider portal for network applications, is a 112 framework that enables Internet Service Providers (ISPs) and network 113 application software developers to work jointly and cooperatively to 114 optimize application communications. The goals of this cooperation 115 are to reduce network resource consumption and to accelerate 116 applications. To achieve these goals, P4P allows ISPs to provide 117 network information and guidance to network applications, allowing 118 clients to exchange data more effectively. In this specification, we 119 focus on peer-to-peer (P2P) applications. 121 The P4P framework was initially developed in the P4P Working Group 122 (P4PWG), hosted by the Distributed Computing Industry Association 123 (DCIA). Many members made contributions to the development and 124 discussion of the framework. The authors of this document recorded 125 the technical development. The complete list of contributors is 126 listed in Appendix A. 128 The P4P framework has been validated by both simulations and field 129 trials from February to August 2008. The goal of this document is to 130 record the technical approach implemented in those trials, and to be 131 a first step in contributing to the production of an eventual 132 industry standard (e.g., in the ALTO working group). This document 133 focuses on the framework, basic concepts, and major features of P4P. 134 Exact protocol specification will be specified in another document, 135 but we give several example messages in Appendix C. Most features 136 presented in this document have been implemented and tested in field 137 tests. There are revisions on the interfaces and their 138 presentations, based on field test experiences, to improve the 139 framework. 141 The specific goals of the P4P include the following: 143 o Allows P2P networks to select the "close" peers for data 144 exchanges, such that data transit cost/distance is minimized and 145 data transfer speed is maximized; 147 o Is extensible and applicable to a wide range of P2P applications 148 including file sharing, multimedia streams, multi-player gaming, 149 auditorium/chat systems, etc. These applications may either 150 include a centralized component (e.g., BitTorrent with trackers, 151 Pando) or be distributed (e.g., Gnutella). 153 o Allows each ISP to manage P4P guidance that is provided for its 154 customers. 156 o Does not specify how ISPs generate their P4P guidance. A 157 configuration language can be used by ISPs to configure their 158 networks, as we did in our field tests. However, this is outside 159 the scope of this document. 161 o ISPs can control the degree of the privacy of information revealed 162 about their networks. ISPs can determine the level of detail that 163 they wish to expose, and apply any desired aggregation and 164 allocation metrics, and all information can be "anonymized" or 165 access-controlled to protect ISP topology and business policies. 167 o Does not specify how P2P networks utilize the information that 168 ISPs provided. Our field tests gave a reference implementation 169 scheme, but this is outside the scope of this document. 171 o P2P networks can choose schemes to avoid exposing user-specific 172 information to ISPs. 174 o Allows "peers" to include a range of data sources, such as 175 standard peers operated by end-users, dedicated "P2P cache 176 servers" operated by ISPs, etc. 178 o Does not specify how multiple ISPs interact or negotiate with 179 respect to their information. This was an interesting issue 180 during the field tests, but it is outside the scope of this 181 document. 183 3. P4P Terminology and Entities 185 This document involves the following terms and entities. 187 o P2P Client: A P2P client, or Peer or Client for short, is run by a 188 user, and creates network connections to endpoints (e.g., clients 189 or servers) in its ISP's network or other ISPs' networks. 191 o Network Location Identifier: It is either an IP address, an IP 192 prefix or an autonomous system number (ASN). 194 o PID: A Partition ID, or a PID for short, is an identifier for a 195 set of Network Location Identifiers (see Section 6.1 for more 196 discussion). It is a generalization of network aggregation 197 concepts such as autonomous system (AS) or OSPF area. It can 198 denote a subnet, a set of subnets, a point of presence (PoP), an 199 Internet exchange point, an autonomous system (AS), a set of 200 autonomous systems (e.g., those with the same next-hop AS, those 201 reachable through provider AS's, or those with the same BGP 202 AS_PATH length), or some other set of Clients with a common set of 203 properties. PIDs provide three primary functions: 205 * Mapping and aggregation of Network Location Identifiers; 207 * Preserving privacy by avoiding identification of individual 208 Clients or specific details of network topology; and 210 * Identifying network resources. 212 Each ISP partitions the Internet address space with a set of PIDs 213 that it defines. This is referred to as the my-Internet view of 214 the ISP (see Section 9.2.3 for more discussion). To differentiate 215 the name space of PIDs from different ISPs, each ISP MUST be 216 identified by a universal identifier (e.g., a unique number 217 assigned by IANA or a URI such as isp1.openp4p.info). Such an 218 identifier is named an ISP identifier. Since many ISPs have 219 multiple ASNs, the PIDs defined within a particular ISP identifier 220 may span multiple ASNs. 222 o pDistances: An ISP network reveals its information and preferences 223 through generalized distances between pairs of Network Location 224 Identifiers or aggregation of Network Location Identifiers (i.e., 225 PIDs). We refer to such distances generically as pDistances. 226 pDistances MAY have attributes. 228 * There MAY exist an attribute indicating the Type of pDistances. 229 Example Types include Routing Hop-Count pDistances, Routing 230 Air-Mile pDistances, and Routing Cost pDistances; see 231 Section 9.1.1 for more discussion. ISPs MUST support Routing 232 Cost pDistances, which are computed internally according to 233 ISPs local state and policies. The Routing Cost pDistances are 234 extensions to path metrics computed by OSPF traffic engineering 235 routing, multihoming optimization, and BGP to unify intradomain 236 routing and interdomain routing to integrate P2P applications 237 [SIGCOMM08]; see Section 9.1.1 for detail. In the absence of 238 the Type attribute, applications SHOULD assume that any 239 pDistances given are Routing Cost pDistances. 241 * There MAY exist an attribute indicating whether a given set of 242 pDistances should be interpreted as either numerical or ordinal 243 (ranking, i.e., the best has a pDistance value of 1, next 2, 244 etc; see [Oracle]). Certain arithmetic operations (e.g., 245 summation) may not be meaningful with ordinal pDistances. The 246 choice of using numerical PID-pair pDistances as the main 247 interface is based on rigorous research derivations 248 [SIGCOMM08]. There are also recent studies (e.g., [NetEcon08]) 249 supporting the completeness of such an interface design. In 250 the absence of this attribute, applications SHOULD assume that 251 given pDistances are numerical. 253 o ISP Portal Service: Each ISP or its delegate provides Portal 254 Services to answer P4P queries [SIGCOMM08]. We refer to the 255 (logical) entity implementing a Portal Service a Portal Server. 256 In the field tests, we also referred to a Portal Server as an 257 iTracker. In this document, we focus on two Portal Services: (1) 258 Location Portal Service and (2) pDistance Portal Service. 259 Multiple Portal Services may run on the same physical machine. A 260 (logical) service may also be implemented using multiple physical 261 machines either in a cluster or an overlay. These physical 262 machines may be interconnected using a protocol (e.g., forming a 263 hierarchy) that is outside the scope of this document. As an 264 example, in our field tests, some Portal Services were implemented 265 using LinuxHA by multiple physical machines for fault tolerance. 266 A Portal Service may be extended by a P2P system to improve 267 scalability. 269 o Location Portal Service: This service answers queries concerning 270 mappings between Network Location Identifiers and PIDs. 272 o pDistance Portal Service: This service answers queries about 273 pDistance between PIDs. 275 o Application Tracker: Many P2P applications use Application 276 Trackers for bootstrapping and coordinating the connections among 277 Clients. Application Trackers may use, among other data, 278 information from Portal Services, to guide or make suggestions to 279 Clients. We also referred to an Application Tracker as an 280 AppTracker or pTracker in the field tests. Note that an 281 Application Tracker is not used by all applications and is an 282 OPTIONAL component of the system. 284 o Application Optimization Engine (AppOE): The Application 285 Optimization Engine is a service introduced in P4P field tests 286 where a (possibly external) entity converts ISP information into a 287 format more directly applicable to the specific application's 288 decision process. An Application Optimization Engine provides 289 three benefits: (1) modular integration of P4P and P2P 290 applications, (2) allowing a P2P application to offload this 291 functionality to a third party, and (3) providing an aggregation 292 point for better management and access control of ISP information. 293 Note that this is an OPTIONAL component of the system, since ISP 294 information may be applied using various other methods. 296 4. P4P Interfaces 298 4.1. Overview 300 To handle diverse P2P application scenarios, the P4P framework adopts 301 an interface-centric design. The design supports heterogenous uses 302 such as tracker-based and tracker-less P2P applications, and also 303 allows applications to integrate P4P information either directly or 304 through a relatively independent module such as an Application 305 Optimization Service. This document focuses on ISP-guided initial 306 Peer selection. 308 The basic P4P information flow for P2P Peer selection involves two 309 services: 311 o The Location Portal Service to map between PIDs and Network 312 Location Identifiers; 314 o The pDistance Portal Service to map the pDistances between network 315 locations. 317 We separate these two services because (1) they provide different 318 functions; and (2) the location information may be large but stable 319 for a much longer time-scale than the pDistance information. 321 With pDistances, an application makes its Peer selection decision by 322 considering not only ISP pDistances but also other data such as 323 application state and policies. 325 Below, we specify more details on the interfaces. The interfaces 326 provided by the Portal Services are discussed. After specifying 327 these interfaces, in the next two sections we present example usages. 328 Example details are given in Appendix C. 330 4.2. Location Portal Service 332 A P4P supporting ISP MUST offer a Location Portal Service that 333 supports mapping between PIDs and Network Location Identifiers. 335 4.2.1. Interfaces 337 The Location Portal Service provides two interfaces. 339 The first interface is named GetPID. In this interface, the Location 340 Portal Service directly performs the mapping from Network Location 341 Identifiers to PIDs. This interface MUST be implemented. 343 o GetPID: This interface takes a list of Network Location 344 Identifiers and returns the corresponding list of PIDs. If the 345 requester supplies an empty list in the request, the reply returns 346 the PID corresponding to the source IP address of the sender's 347 request. 349 The second interface is named GetPIDMap. This interface provides 350 information to applications so that they can perform the mapping from 351 Network Location Identifiers to PIDs themselves. There are three 352 advantages with this interface: (1) reducing the querying load on ISP 353 Portal Service; (2) reducing application latency; and (3) protecting 354 individual Client privacy. This interface SHOULD be implemented. 356 o GetPIDMap: This interface returns a mapping from PIDs to lists of 357 Network Location Identifiers. If an empty list of PIDs is 358 specified in the request, the reply MAY include the mappings for 359 PIDs that can define Routing Cost pDistances. If a list of PIDs 360 is specified in the request, the reply returns only the mappings 361 for those PIDs or a subset of those PIDs. 363 4.2.2. Querying Entities 365 The Location Portal Service may be queried by any entity requiring 366 mappings between PIDs and Network Location Identifiers. We name two 367 possibilities here. 369 o A Client may directly query its Location Portal Service through 370 the GetPID interface. The PID may then be sent to other endpoints 371 with which the Client is communicating, such as other Clients or 372 an Application Tracker (if one is used). See Section 9.2.2 for 373 further discussion. 375 o An Application Tracker or another entity (AppOE) may query the PID 376 of a Client, either due to a design consideration or because of 377 incremental deployment (e.g., delegate queries for unmodified 378 Clients). 380 4.3. pDistance Portal Service 382 A P4P supporting ISP MUST offer a pDistance Portal Service. 384 4.3.1. Interface 386 The pDistance Portal Service answers queries concerning pDistances 387 between Network Location Identifers and PIDs. 389 This service MUST provide the following interface: 391 o GetpDistances: This interface takes as input a list of PID->PID 392 pairs and desired attributes (e.g., Type) of the pDistances. The 393 reply is a list of PID->PID pairs (it may be a subset of those 394 supplied in the request) and their associated pDistances. The 395 requester may specify pairs of Network Location Identifiers 396 instead of pairs of PIDs in the request. In such a case, the 397 reply will be pDistances for the specified pairs of Network 398 Location Identifiers. 400 5. Example Usage of P4P Interfaces 402 The P4P interfaces may be used in a variety of ways by ISPs and 403 applications depending on their particular behavior and requirements. 404 In this section, we provide examples of how the interfaces can be 405 queried in some typical scenarios. 407 5.1. Example E1: Querying for Individual Client Addresses 409 One way to provide guidance to applications is to issue a request for 410 each new Client. 412 Specifically, in this usage case, when a new Client of an ISP joins, 413 the Client or Application Tracker issues a GetpDistances query for 414 the IP address (or IP prefix) of the Client and a list of IP 415 addresses (or IP prefixes) of candidate Peers. 417 The application then selects Peers internally by attempting to meet 418 application-specific requirements and utilizing the returned 419 pDistances to account for ISP guidance. 421 5.2. Example E2: Aggregated Query Using PIDs 423 An issue of the preceding usage scenario is that it may impose 424 significant load on the Application Tracker (if there is one and it 425 performs the query) and the ISP pDistance Portal. Privacy is another 426 concern, since the IP address of the Client is directly linked to 427 other Clients' IP addresses and they are possibly downloading the 428 same content since they are queried together. Due to these issues, 429 the preceding usage scenario was not used in our field tests. 430 Instead, an application can use PIDs for aggregation. PIDs allow 431 ISPs to aggregate "like" Clients, for example, Clients in the same 432 metropolitan area. We consider an example when there is an 433 Application Tracker. 435 An Application Tracker keeps track of Clients in the system. With 436 P4P, the Application Tracker will also need to maintain ISP 437 information. If there exists a Client that has a given PID-p of 438 ISP-i, we say that PID-i is active in ISP-i. Consider an 439 implementation where the Application Tracker maintains two additional 440 data structures for each ISP: (1) the pDistance table for the 441 pDistances among those active PIDs of the ISP; and (2) the Clients at 442 each active PID of the ISP. The second data structure helps the 443 Application Tracker to quickly select Peers from a given PID. 445 When a new Client, Client-a, from ISP-i joins but does not report its 446 PID, the Application Tracker looks up the PID of Client-a (e.g., 447 either using GetPID or looking up in the local PID Map if the 448 Application Tracker has called GetPIDMap for ISP-i). If the PID of 449 Client-a is already active, the Application Tracker can make Peer 450 selection for Client-a utilizing the current pDistance table (or 451 derived guidance structure such as a peering weight data structure); 452 otherwise, the Application Tracker queries the pDistance Portal of 453 ISP-i to extend its pDistances table for ISP-i to include the new 454 PID. Note that for Client-a to be selectable as a Peer when a Client 455 from another ISP joins, the PIDs of Client-a for other ISPs need to 456 be resolved, and inserted into other ISPs' second data structure. 457 This can be done in a background process using a queue, and may be 458 done for only a subset of ISPs other than ISP-i to improve 459 scalability. 461 5.3. Example E3: Utilizing an Application Optimization Service 463 The Application Optimization Service is a technique we introduced in 464 P4P to convert ISP pDistances disseminated by ISP Portal Services 465 into a format more-directly applicable for guiding application 466 behavior. The intentions of introducing this service are: (1) 467 achieving modular integration of P4P and P2P applications; (2) 468 allowing a P2P application to offload this functionality to a third 469 party; and (3) providing an information aggregation point for ISPs to 470 control the distribution of their information. 472 It is important to note that the Application Optimization Service 473 utilizes the previously-defined ISP Interfaces. Application 474 Optimization Services could be provided by ISPs as an additional 475 interface (to augment the mandatory interfaces), by third-parties, or 476 integrated as a component of a P2P application. 478 Since the Application Optimization Service provides guidance specific 479 to an application or class of applications, the information and 480 format will vary depending on the application. 482 The following diagram shows how an Application Optimization Service 483 may be used to transform ISP pDistances into application-specific 484 information. 486 [App-specific 487 .----------. PIDs .--------------. state] .--------------. 488 | ISP pDis | <----- | Application | <--------- | | 489 | Portal | | Optimization | | Application | 490 | Service | -----> | Service | ---------> | | 491 `----------' pDist `--------------'App-specific`--------------' 492 or generic 493 guidance 495 Figure 1: Information flow when there is Application Optimization 496 Service. 498 Note that an Application Optimization Service may provide generic 499 guidance that does not make use of application state information. In 500 such a case, an application may simply request generic guidance 501 without supplying application-specific state information. Note that 502 generic guidance may still depend on the type of application (e.g., 503 file sharing vs streaming). In our field tests for file sharing, we 504 achieved good performance with generic guidance. 506 Since the format of the guidance provided from the Application 507 Optimization Service is particular to the type of application (file 508 sharing and streaming may choose peering differently), next we give 509 an example of using an Application Optimization Service for file 510 sharing. 512 In the field tests, an Application Optimization Service for P2P file- 513 sharing applications is implemented. It defines this simple 514 interface: 516 o GetPeeringWeights: The request optionally includes swarm state 517 information as a list of PIDs, and for each PID, the number of 518 seeds and leechers and the aggregated download and upload capacity 519 of clients within the PID. The response is a matrix of peering 520 weights amongst the PIDs included in the request, as computed from 521 the set of pDistances currently pulled from Portal Servers. If 522 the request included swarm information, the returned weight matrix 523 is tailored for the current state of the swarm. Otherwise, the 524 returned matrix is generic guidance that can be used across 525 different swarm states. 527 The Application Optimization Service implemented for the field test 528 periodically retrieved updated pDistances from ISP pDistance Portal 529 Services. 531 6. Extended Usage of PIDs 533 In this section we illustrate how the flexibility of PIDs caters to 534 more diverse usage scenarios by both applications and ISPs. Such 535 usage scenarios are not tested in previous tests. However, they do 536 not require any modification to the communication protocol. In 537 particular, we show how PIDs support caches and simple avoid/prefer 538 lists. 540 We first give more details on PIDs. Then we provide usage scenarios. 542 6.1. PID Type 544 Although PIDs are always used for aggregation, we identify that they 545 may aggregate different types of objects. The preceding section uses 546 PIDs to aggregate network locations. It is also possible to use a 547 PID to aggregate a set of network resources. We call the first type 548 Aggregation PIDs and the second Resource PIDs. 550 6.1.1. Aggregation PIDs 552 Aggregation PIDs are used to group "like" clients (identified by 553 Network Location Identifiers) into PIDs. Aggregation PIDs allow an 554 ISP to perform customized aggregation of Network Location Identifiers 555 for its network and locations external to its network. 557 Note that there is a well-known PID named PID_ISP_DEFAULT which 558 implicitly contains all Network Location Identifiers not contained by 559 other Aggregation PIDs. Mapping of an IP address to a set of 560 Aggregation PIDs is always based on the most specific matching. See 561 Section 9.1.3 for more details. 563 6.1.2. Resource PIDs 565 A Resource PID is used to identify a particular available resource 566 (e.g., caches) to applications. The objects aggregated by a Resource 567 PID may be Endpoint Identifiers (an IP address and associated 568 attributes such as port number, protocol, authorization, etc). Thus, 569 when Resource PIDs are enumerated by the Location Portal Interface, 570 each returned PID should be mapped to a list of Endpoint Identifiers. 572 This framework defines some specific Resource PIDs with well-known 573 semantics, but others may be allocated by an organization such as the 574 IANA. 576 6.2. Example X1: Using PIDs to Identify Caches 578 Some Resource PIDs are used to identify caches available in an ISP. 579 An application uses GetPIDMap on the following Resource PIDs to 580 obtain caches in an ISP network: 582 o PID_RES_PUBLIC_CACHE: enumerates a set of caches publicly 583 available in the ISP network; 585 o PID_RES_PRIVATE_CACHE: enumerates a set of caches, but demands 586 authorization before doing so. 588 After an application obtains a list of Endpoint Identifiers from the 589 GetPIDMap interface for a Resource PID identifying caches, it can 590 then get pDistances to these endpoints by mapping the IP addresses of 591 the identified caches into Aggregation PIDs and then querying the 592 GetpDistance interface. There is an additional approach to obtain 593 caches. Please see Section 9.1.5. 595 Note that additional Resource PIDs may be defined for caches 596 understanding specific protocols. For example, there can be Resource 597 PIDs that identify caches for BitTorrent. 599 6.3. Example X2: Using PIDs for ISP AVOID/PREFER 601 An ISP may wish to reveal some or all of its preferences in the form 602 of preferring or avoiding specific Network Location Identifiers. The 603 usage of avoid/prefer is motivated and similar to the proposal in 604 [p2pi-Shalunov]. As an example, consider an ISP network with two 605 types of customers. The first type (type I) may have limited upload 606 capacity. Thus, the ISP may prefer that the first type of customers 607 do not generate a large amount of upload traffic to others. 609 One possible way to reflect this preference is the following. The 610 ISP configures the Location Portal Service to define an Aggregation 611 PID named PID_ISP_AVOID in addition to PID_ISP_DEFAULT: 613 o PID_ISP_AVOID: avoided Network Location Identifiers. 615 Then, Clients with Network Location Identifiers defined in 616 PID_ISP_AVOID will be given PID_ISP_AVOID, and those outside will be 617 given PID_ISP_DEFAULT. 619 The ISP configures its Routing Cost pDistances as those in Figure 2, 620 where MIN_PDISTANCE and MAX_PDISTANCE are the minimum and maximum 621 pDistance values respectively. In particular, upload from the 622 avoided sources (i.e., type I) is configured with the maximum 623 pDistance while upload from the preferred sources (i.e., the other 624 type) is configured with the minimum pDistance. 626 Destination 628 | PID_ISP_DEFAULT | PID_ISP_AVOID | 629 ---------------------------------------------------| 630 PID_ISP_DEFAULT | MIN_PDISTANCE | MIN_PDISTANCE | 631 Source ---------------------------------------------------| 632 PID_ISP_AVOID | MAX_PDISTANCE | MAX_PDISTANCE | 633 ---------------------------------------------------' 635 Figure 2: pDistances for implementing ISP AVOID/PREFER. 637 An ISP can extend beyond two levels of preferences and configure 638 multiple tiers using a similar approach. 640 7. Portal Server Discovery 642 The field tests used manual configuration for the discovery of 643 Location and pDistance Servers. In the P4P framework design, 644 possibilities include DNS SRV (e.g., BEP 22). As another 645 possibility, Portal Servers can be found through a P4P DNS hierarchy. 646 For example, for a Client with IP address a.b.c.d to find its Portal 647 Servers, it may query for d.c.b.a.openp4p.org, where openp4p.org 648 conducts mapping from IP addresses to their Portal Servers. 650 A key issue in discovering the Portal Servers is delegation. In our 651 field tests, multiple ISPs proposed the possibility of delegation: an 652 ISP provides information for costumer networks that may not want to 653 run Portal Servers themselves. An ideal solution is that such 654 networks have their DNS entries pointing to the delegation Portal 655 Servers. Thus, a DNS based solution may be more ideal. 657 8. Security Considerations 659 There are security considerations from the perspectives of both ISPs 660 and P2P applications. 662 8.1. Security Considerations for ISPs 664 o ISPs MAY wish to implement access control to some or all P4P 665 interfaces to only trusted entities. This can be achieved, for 666 example, by running the interfaces on top of TLS/SSL. However, 667 the exact mechanism for access control, authentication, and 668 confidentiality of message transport is outside the scope of this 669 document. 671 o ISPs need to evaluate how much information to reveal and the 672 associated risks. For example, revealing extremely fine-grained 673 information may make it easier to determine network topology while 674 revealing overly coarse-grained information may not provide 675 benefits to the ISP or to applications. Also, a malicious 676 attacker may target those PID-pairs with high pDistances. To 677 alleviate these risks, ISPs may apply several techniques, 678 including (1) aggregation (e.g., a single PID for intradomain to 679 block internal topology and reveal only interdomain preferences); 680 (2) perturbation of revealed information; and (3) access control 681 (see above). A related comment is that some information that the 682 pDistance Portal reveals is not secret information. For example, 683 information based on hop-count and air-miles is largely measurable 684 by Clients themselves (e.g., when there is no MPLS). 686 o Another risk that ISPs need to evaluate is that some other ISPs 687 may distribute information leading to less desirable traffic 688 patterns. In the P4P architecture, the preference of an ISP is 689 applied only when the new client is from the ISP. This 690 distributes the control of ISPs. However, one can still envision 691 scenarios where an ISP may have a sufficient number of Clients 692 where guidance can affect another ISP. 694 8.2. Security Considerations for P2P Applications 696 P2P applications may encounter ISP behaviors that would be considered 697 hostile from their perspective. Consider the following examples. 699 o The PIDs may be fine-grained. Although querying the interfaces 700 does not link to any particular content, it may help ISPs to track 701 Clients. One potential technique to alleviate this issue is that 702 the application truncates IP addresses. Another technique is to 703 use only GetPIDMap. 705 o There is a risk that ISPs could provide ineffective guidance. For 706 example, the network pDistances (either Routing related pDistances 707 or Routing Cost pDistances) configured by an ISP may lead to lower 708 application performance. To address this issue, it is important 709 that applications are robust and detect such behaviors, possibly 710 through community efforts. Applications may still use other 711 mechanisms to complement ISP guidance or replace ISP guidance when 712 it is ineffective. 714 o Some ISP Portals may be poorly provisioned or even intentionally 715 under-provisioned, leading to substantial delay. Applications 716 should be designed to tolerate failure of ISP portals. For 717 example, in our field tests, ISP information is cached. 719 9. Discussion and Extensions 721 There are many considerations that contributed to the design of these 722 P4P interfaces. This section further elaborates on some items. 724 9.1. ISP Information 726 9.1.1. pDistance Semantics and Calculation 728 Motivated by OSPF, which provides multiple types of link metrics, we 729 allow multiple Types of pDistances. It is important that the 730 semantics of a given Type of pDistance is as well defined as 731 possible. For example, Routing Hop-Count pDistance, Routing Air-Mile 732 pDistance, and Routing Cost pDistance represent the number of hops, 733 the air milage, and the traffic engineering cost of transmitting one 734 bit from a given source network location to a given destination 735 network location, respectively. 737 However, application developers should be aware that there is 738 inherent approximation when an ISP computes and reveals such 739 information. We discuss two illustrative examples. 741 Routing Hop-Count pDistances: given a pair of Internet hosts, the 742 routing hop count from a source to a destination is typically well- 743 defined. However, the pDistance computed by the ISP may be an 744 approximation. There are multiple reasons. 746 o First, when the ISP provides pDistance between a pair of PIDs 747 instead of end hosts, it may approximate the hop count pDistance 748 as the average hop count between end hosts within those PIDs. For 749 potentially better accuracy, the pDistance Portal allows queries 750 using Network Location Identifiers. However, the ISP may still 751 choose to internally map Network Location Identifiers into PIDs 752 and then return pDistances. 754 o Second, if a PID represents a location outside the ISP, the ISP 755 may need to merge its intradomain and interdomain routing 756 information. Thus, the hop count from a PID representing a 757 location inside the ISP to a PID representing a location outside 758 the ISP, may be the sum of intradomain hop count and interdomain 759 BGP hop count. In our early design, two metric spaces were 760 considered: one metric space for the pDistances among PIDs inside 761 the ISP, and the other metric space for the pDistances from PIDs 762 inside the ISP to PIDs outside the ISP. The pDistances from these 763 two metric spaces are not comparable. However, multiple scenarios 764 were identified where an ISP may prefer some interdomain 765 connections over some intradomain connections. In the current 766 design, a single metric space to define pDistances allows ISPs to 767 define a uniform policy. 769 Routing Cost pDistance: In traditional Internet OSPF traffic 770 engineering, an ISP computes effective OSPF link costs to improve 771 routing efficiency [OSPF-TE]. The P4P Routing Cost pDistances are 772 extensions to traditional OSPF traffic engineering costs to integrate 773 P2P applications. However, different ISPs may have different traffic 774 engineering cost metrics. Thus, there is inherent fuzziness when 775 defining Routing Cost pDistances. In the July 2008 field test, we 776 found that the ISPs approximated their Routing Cost pDistances in a 777 variety of ways, including air-miles, hop counts, and OSPF-derived 778 costs. An interesting observation from our studies is that there was 779 strong positive correlation between ISP-configured pDistances and 780 geographic distances. 782 9.1.2. pDistance Direction 784 Also motivated by OSPF, we allow pDistance to be asymmetric: the 785 pDistance from PID_1 to PID_2 can be different from PID_2 to PID_1. 786 One issue to consider when using such information for Peer selection, 787 however, is that it is in general hard to predict the traffic 788 direction between a pair of Clients. Another issue is that the 789 routing system of an ISP may not have accurate information from a PID 790 outside its network to a PID inside its network. 792 9.1.3. Aggregation PIDs 794 There are subtle issues involved in defining Aggregation PIDs. We 795 discuss some of them. 797 The Aggregation PIDs are particularly important for interdomain. For 798 example, instead of specifying hundreds of thousands of IP prefixes 799 in the global Internet, or tens of thousands of autonomous systems, 800 Aggregation PIDs may allow an ISP to specify pDistances for a much 801 smaller set of objects. Note that such aggregation will payoff only 802 if the mapping from Clients to PIDs can be obtained at a low cost 803 (e.g., through a database without involving the ISP), or the mapping 804 is more stable and the pDistances are more frequently queried. 806 Aggregation may depend on the location inside an ISP network. This 807 is particularly so for BGP. For example, the intention of an 808 Aggregation PID may be a set that includes all external IP 809 destinations using a given interdomain exchange point. This set may 810 depend on the source location inside the ISP network. Thus, an 811 external destination AS may have multiple exist points. Defining a 812 PID for each destination with multiple exist points may require 813 defining too many PIDs. An ISP may apply technique (e.g., choosing 814 only the top or randomization) to reduce the number of such PIDs. 816 We allow an ASN to be a Network Location Identifier for scalability 817 and convenience. An ASN typically is used to identify an aggregated 818 location outside of an ISP. The BGP tables of the routers of an ISP 819 define association between an IP address and its origin ASN. An 820 issue arises, for example, when an Application Tracker uses PID maps 821 and the definition of a PID includes ASNs. Since the Application 822 Tracker does not have access to the BGP tables of the ISP, it needs a 823 method to map from IP addresses to ASNs. Thus, if a PID includes 824 ASNs, the ISP may need to ensure that applications can achieve 825 reasonably accurate mapping from IP addresses to the used ASNs. In 826 our field tests, an Application Tracker used a public database to 827 conduct this mapping. Note that using this database may introduce 828 errors. 830 There is a possibility that two PIDs defined by an ISP overlap; that 831 is, an IP address belongs to the Network Location Identifiers of both 832 PIDs. For the purpose of mapping this IP address to a PID, we assume 833 that ASN has precedence over IP prefix. Among IP prefixes, the 834 longest prefix match takes precedence. If two ASNs from two 835 different PIDs contain the IP address, one of them is picked 836 arbitrarily. 838 9.1.4. Hierarchical PIDs 840 It is possible to impose a hierarchical structure on PIDs to improve 841 scalability and allow delegation among Portal Servers (e.g., when 842 defining pDistances). For example, an ISP, isp1, may assign a Client 843 within its network a PID such as subpid1.pid1.intra.isp1, which 844 denotes that the Client belongs to subpid1, which is a part of pid1, 845 which is a part of the internal network of isp1. A Client outside 846 isp1 may be assigned a PID such as asn100.pid_exit_point.exter.isp1, 847 which denotes that the external Client is seen as originated from ASN 848 100, and will take the exit point denoted by pid_exit_point. This 849 hierarchical format allows easier checking on whether two Clients are 850 within the same hierarchy. However, this is outside the scope of 851 this document. 853 9.1.5. PID Attributes 855 During our early field tests, some ISPs were able to provide 856 additional information such as Client access type (e.g., ADSL 1Mbps 857 down/384kbps up) and geographical location (to a certain precision). 858 One may also query the caches that are close to a PID. As another 859 example, some ISPs provide geo-location of PIDs. 861 Such information may be encoded as the attributes of a PID. To 862 support queries on such information, we can add a new interface: 864 o GetPIDAttribute, which takes as input a PID and the desired 865 attribute type, and returns the value of the attribute. 867 9.2. Scalability 869 Scalability of the interfaces is a major design consideration. We 870 discuss several items. 872 9.2.1. Caching P4P Information 874 It is recommended that the reply from Portal Services should include 875 a lifetime attribute to facilitate caching. This is not provided in 876 the current specification as it was not implemented in the field 877 tests. 879 9.2.2. Client PID Retrieval 881 To improve scalability, it is suggested that Clients directly query 882 their Location Portal Service through the GetPID interface for their 883 PIDs either at startup, or when first needed. Since a PID is 884 application-agnostic and content-independent, it may be cached for a 885 period of time within the Client and used across applications and 886 communicated with other endpoints. 888 9.2.3. Global PIDs and my-Internet View 890 A major scalability challenge of using ISP information by a P2P 891 application is that the application needs to handle the "my-Internet" 892 views of multiple ISPs. The my-Internet view concept is strongly 893 prefered by some ISPs in configuring their networks during our field 894 tests. 896 In applications where Clients are concentrated in a few ISPs, such 897 multiple views may not be an issue. Also, the application may choose 898 to handle only the top ISPs to reduce overhead. Furthermore, the 899 application may not need to always resolve the PID of Client outside 900 its home ISP. 902 From our experiences, specifying interdomain information contributes 903 to a large fraction of ISP specification, as interdomain may involve 904 hundreds of thousands of IP prefixes and/or tens of thousands of 905 autonomous systems. Globally consistent PIDs (e.g., based on ideas 906 such as [GeoIDRouting07]) when defining PIDs for locations outside an 907 ISP may improve scalability. Such an approach may also allow PID 908 maps from different ISPs to be linked, for example, at peering or 909 exchange points. However, this requires coordination among the 910 "views" of different ISPs. 912 9.2.4. Granularity of Information 914 ISPs should be mindful of overloading applications with overly- 915 detailed data. In one possible extreme case, an ISP could configure 916 its Location Portal Service to define a large number of PIDs (e.g., 917 one for each CMTS or DSLAM). 919 Applications, however, may need to store data from multiple Portal 920 Servers. If the provided data is extremely fine-grained, an 921 application may not have the resources to store or process such data. 922 In such a case, the application can revert to ignoring ISP-provided 923 guidance. Since ISP-provided guidance can benefit the ISP, there are 924 incentives to provide P4P information compact enough such that 925 applications may store and process it, yet also conveying the desired 926 preferences. 928 10. References 930 10.1. Normative References 932 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 933 Requirement Levels", BCP 14, RFC 2119, March 1997. 935 10.2. Informative References 937 [GeoIDRouting07] R. Oliveira, M. Lad, B. Zhang, L. Zhang, 938 "Geographically Informed Inter-domain Routing", In 939 ICNP 2007. 941 [NetEcon08] P. Laskowski, B. Johnson, and J. Chuang, "User- 942 Directed Routing: From Theory, towards Practice", 943 In ACM NetEcon 2008. 945 [OSPF-TE] B. Fortz and M. Thorup, "Internet traffic 946 engineering by optimizing OSPF weights", In IEEE 947 INFOCOM 2000. 949 [Oracle] Vinay Aggarwal, Anja Feldmann, Christian 950 Scheideler, "Can ISPs and P2P systems co-operate 951 for improved performance?", In CCR 2007. 953 [SIGCOMM08] H. Xie, Y.R. Yang, A. Krishnamurthy, Y. Liu, and A. 954 Silberschatz., "P4P: Provider Portal for (P2P) 955 Applications", In ACM SIGCOMM. 2008. 957 [p2pi-Shalunov] S. Shalunov. In p2pi discussion list: http:// 958 www.ietf.org/mail-archive/web/p2pi/current/ 959 msg00508.html, "ALTO service privacy, performance, 960 and architecture", 2008. 962 Appendix A. Contributors 964 The P4P project includes contributions from many members of the P4P 965 Working Group, hosted by DCIA. 967 The individuals involved in the design and P4P field tests include 968 (in alphabetical order): 970 o Richard Alimi, Yale University 972 o Alex Gerber, AT&T 974 o Chris Griffiths, Comcast 976 o Ramit Hora, Pando Networks 978 o Arvind Krishnamurthy, University of Washington 980 o Y. Grace Liu, IBM Watson 982 o Jason Livingood, Comcast 984 o Michael Merritt, AT&T 986 o Doug Pasko, Verizon 988 o Laird Popkin, Pando Networks 990 o James Royalty, Pando Networks 992 o Thomas Scholl, AT&T 994 o Emilio Sepulveda, Telefonica 996 o Avi Silberschatz, Yale 998 o Hassan Sipra, Bell Canada 1000 o Haibin Song, Huawei 1002 o Oliver Spatscheck, AT&T 1004 o Jia Wang, AT&T 1006 o Richard Woundy, Comcast 1007 o Hao Wang, Yale University 1009 o Ye Wang, Yale University 1011 o Haiyong Xie, Yale University 1013 o Y. Richard Yang, Yale University 1015 Appendix B. Acknowledgments 1017 The authors would like to thank the members of the P4P Working Group 1018 for their collaboration, and the members of the p2pi mailing list for 1019 their comments and questions. We would like to think Marty Lafferty 1020 from DCIA, Erran Li, Jin Li, See-Mong Tang, and Yu-Shun Wang for 1021 reading the document and giving us excellent feedback. 1023 Appendix C. P4P Protocol Example 1025 C.1. Overview 1027 In this section we provide example message flows to illustrate how 1028 P2P applications may request P4P information from ISP Portal Services 1029 and how P4P information can be used. Note that the examples below 1030 are not traces from our field tests, but rather are constructed to be 1031 illustrative. Our field test implementation used WSDL to specify P4P 1032 interfaces, and SOAP as the encoding. Exact messaging format will be 1033 presented in a spec document. Below, we give interface invocations 1034 without giving the encoding. In the example, we use strings as PIDs. 1035 We also do not include the ISP identifier since we consider a single 1036 ISP. 1038 We begin with an example similar to the tracker-based example in 1039 Section 5.2. We also include a variant for tracker-less systems. 1041 C.2. ISP Portal Service Configuration 1043 An ISP configures its Location Portal Service to maintain the mapping 1044 of Network Location Identifiers to PIDs, and configures the 1045 pDistances between each pair of PIDs in the pDistance Portal Service. 1047 In this example, the ISP defines five Aggregation PIDs in addition to 1048 PID_ISP_DEFAULT. Three of these PIDs represent intradomain IP 1049 addresses, PID_EAST, PID_WEST, and PID_MIDDLE, which relate to their 1050 geographic locations. These three PIDs will be marked as INTRA. The 1051 remaining two PIDs represent interdomain endpoints: PID_EX_EAST is 1052 configured with IP addresses and ASNs reached through peering links 1053 in the east; PID_EX_WEST is configured with those reached through 1054 peering links in the west. They will be marked as EXTER. 1056 The ISP prefers traffic to remain in the same geographic area, so it 1057 configures the pDistance from PID_EAST to PID_EAST to be 0, and 1058 similarly for PID_WEST and PID_MIDDLE. To express its preference for 1059 intradomain over interdomain traffic, the remaining pDistances 1060 amongst the intradomain PIDs PID_EAST, PID_WEST, and PID_MIDDLE are 1061 configured smaller than pDistances between intradomain PIDs and the 1062 interdomain PIDs PID_EX_EAST and PID_EX_WEST. 1064 C.3. Tracker-based P2P Application 1066 In a tracker-based file-sharing P2P application, the Application 1067 Tracker maintains the swarm state. In this example, it retrieves P4P 1068 information directly from the ISP's Portal Service. Finally, it uses 1069 the information to optimize the initial Peer selection. 1071 1. The Application Tracker queries the ISP's Location Portal Service 1072 to retrieve the PID map: 1074 GetPIDMap Request 1076 Parameter: none (indicating a request for a map of 1077 all PIDs defined by the ISP). 1079 GetPIDMap Response 1081 PID_ISP_DEFAULT 0/0 1082 PID_EAST INTRA 128.36.0.0/16 1083 PID_MIDDLE INTRA 216.8.0.0/16 1084 PID_WEST INTRA 206.0.0.0/8 209.234.0.0/16 1085 PID_EX_EAST EXTER AS294 77.0.0.0/8 93.0.0.0/8 1086 PID_EX_WEST EXTER AS4571 AS4981 112.0.0.0/8 126.0.0.0/8 1088 2. Six Clients (Peers) join the swarm. Each Peer reports its IP 1089 address to the Application Tracker. Application Tracker locally 1090 determines each Peer's PID from the PID map. 1092 Client 128.36.233.132: PID_EAST 1093 Client 112.72.31.251: PID_EX_WEST 1094 Client 206.8.179.24: PID_WEST 1095 Client 93.132.128.199: PID_EX_EAST 1096 Client 128.36.233.98: PID_EAST 1097 Client 126.199.253.7: PID_EX_WEST 1099 3. The Application Tracker queries the pDistance Portal Service for 1100 pDistances. Only the active PIDs (see Section 5.2) are specified 1101 in the request. Note that the response does not contain the full 1102 pDistance matrix. 1104 GetpDistance Request 1106 Parameter: 1108 PID_EAST PID_EAST 1109 PID_EAST PID_WEST 1110 PID_EAST PID_EX_WEST 1111 PID_EAST PID_EX_EAST 1112 PID_WEST PID_EAST 1113 PID_WEST PID_WEST 1114 PID_WEST PID_EX_WEST 1115 PID_WEST PID_EX_EAST 1116 PID_EX_WEST PID_EAST 1117 PID_EX_WEST PID_WEST 1118 PID_EX_EAST PID_EAST 1119 PID_EX_EAST PID_WEST 1121 GetpDistance Response 1123 PID_EAST PID_EAST 0 1124 PID_EAST PID_WEST 15 1125 PID_EAST PID_EX_WEST 140 1126 PID_EAST PID_EX_EAST 75 1127 PID_WEST PID_EAST 16 1128 PID_WEST PID_WEST 0 1129 PID_WEST PID_EX_WEST 92 1130 PID_WEST PID_EX_EAST 128 1131 PID_EX_WEST PID_EAST 140 1132 PID_EX_WEST PID_WEST 92 1133 PID_EX_EAST PID_EAST 75 1134 PID_EX_EAST PID_WEST 128 1136 4. When a Client at PID_WEST or PID_EAST requests a set of Peers 1137 from the Application Tracker, the Application Tracker determines 1138 the PID for the requesting Peer, and constructs a Peer list for 1139 the Client. 1141 C.4. Tracker-less P2P Application 1143 We now present a simple example for a tracker-less P2P application. 1144 This approach may be used for tracker-less P2P protocols, or for 1145 cases where an Application Tracker does not support P4P. 1147 1. A Client begins by querying the Location Portal Service's GetPID 1148 interface at startup (see Section 9.2.2) to find its PID. 1150 GetPID Request 1152 Parameter: none (indicating a request for the client's PID). 1154 GetPID Response 1156 PID_EAST INTRA 1158 2. After the Client obtains a Peer list (e.g., from a DHT or 1159 gossiping), it queries the Location Portal Service to find the 1160 PIDs of the Peers in the list. The GetPID request now includes a 1161 list of the IP addresses of potential Peers. IP addresses are 1162 truncated to increase privacy. 1164 GetPID Request 1166 Parameter: 1168 128.36.233.0 1169 112.72.31.0 1170 206.8.179.0 1171 93.132.128.0 1172 128.36.233.0 1173 126.199.253.0 1175 GetPID Response 1177 128.36.233.0 PID_EAST INTRA 1178 112.72.31.0 PID_EX_WEST EXTER 1179 206.8.179.0 PID_WEST INTRA 1180 93.132.128.0 PID_EX_EAST EXTER 1181 128.36.233.0 PID_EAST INTRA 1182 126.199.253.0 PID_EX_WEST EXTER 1184 3. The Client queries the pDistance Portal Service to determine the 1185 pDistances between itself and the Peers in the list. The Client 1186 supplies its own PID together with other Peers' PIDs in the 1187 GetpDistance request. 1189 GetpDistance Request 1191 Parameter: 1193 PID_EAST PID_EAST 1194 PID_EAST PID_WEST 1195 PID_EAST PID_EX_EAST 1196 PID_EAST PID_EX_WEST 1198 GetpDistance Response 1200 PID_EAST PID_EAST 0 1201 PID_EAST PID_WEST 15 1202 PID_EAST PID_EX_EAST 75 1203 PID_EAST PID_EX_WEST 140 1205 4. The Client then prefers Peers whose PIDs have smaller pDistances. 1207 5. When the Client receives a new Peer list (for example, through 1208 gossiping), it queries GetPID to map the newly-discovered Peers 1209 to PIDs, and obtains pDistances if necessary. 1211 Authors' Addresses 1213 Richard Alimi 1214 Yale University 1216 EMail: richard.alimi@yale.edu 1218 Doug Pasko 1219 Verizon 1221 EMail: doug.pasko@verizon.com 1223 Laird Popkin 1224 Pando Networks, Inc. 1226 EMail: laird@pando.com 1228 Ye Wang 1229 Yale University 1231 EMail: ye.wang@yale.edu 1233 Y. Richard Yang (editor) 1234 Yale University 1236 EMail: yry@cs.yale.edu 1238 Full Copyright Statement 1240 Copyright (C) The IETF Trust (2008). 1242 This document is subject to the rights, licenses and restrictions 1243 contained in BCP 78, and except as set forth therein, the authors 1244 retain all their rights. 1246 This document and the information contained herein are provided on an 1247 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1248 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1249 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1250 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1251 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1252 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1254 Intellectual Property 1256 The IETF takes no position regarding the validity or scope of any 1257 Intellectual Property Rights or other rights that might be claimed to 1258 pertain to the implementation or use of the technology described in 1259 this document or the extent to which any license under such rights 1260 might or might not be available; nor does it represent that it has 1261 made any independent effort to identify any such rights. Information 1262 on the procedures with respect to rights in RFC documents can be 1263 found in BCP 78 and BCP 79. 1265 Copies of IPR disclosures made to the IETF Secretariat and any 1266 assurances of licenses to be made available, or the result of an 1267 attempt made to obtain a general license or permission for the use of 1268 such proprietary rights by implementers or users of this 1269 specification can be obtained from the IETF on-line IPR repository at 1270 http://www.ietf.org/ipr. 1272 The IETF invites any interested party to bring to its attention any 1273 copyrights, patents or patent applications, or other proprietary 1274 rights that may cover technology that may be required to implement 1275 this standard. Please address the information to the IETF at 1276 ietf-ipr@ietf.org.