idnits 2.17.1 draft-wang-alto-privacy-load-analysis-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (October 16, 2009) is 5299 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.akonjang-alto-proxidor' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'I-D.wang-alto-p4p-specification' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'I-D.penno-alto-protocol' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'I-D.song-alto-server-discovery' is defined on line 553, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-01 == Outdated reference: A later version (-04) exists of draft-penno-alto-protocol-03 == Outdated reference: A later version (-03) exists of draft-song-alto-server-discovery-01 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Y. Wang, Ed. 3 Internet-Draft H. Song 4 Intended status: Standards Track M. Chen 5 Expires: April 19, 2010 Huawei 6 October 16, 2009 8 Analysis for ALTO privacy and load issues 9 draft-wang-alto-privacy-load-analysis-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 19, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The goal of Application-Layer Traffic Optimization (ALTO) is to 48 provide guidance to applications, which have to select one or several 49 hosts from a set of candidates, which are able to provide the desired 50 resource. Now the members in alto group propose many solutions, such 51 as P4P and PROXIDOR. These solutions still have unsolved problems 52 regarding privacy and workload. The privacy and load issues are 53 crucial aspects for the benefits of ISP and P2P.This draft is to do a 54 comparative study to analyze and compare the privacy and workload of 55 several existing solutions, hence to provide guidance in order to 56 improve, optimize and deploy the protocol. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4 63 3. Privacy consideration . . . . . . . . . . . . . . . . . . . . 4 64 3.1. ISP privacy . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. P2P privacy . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Workload considerations . . . . . . . . . . . . . . . . . . . 5 67 4.1. ISP load . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.2. P2P load . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Solution space analysis . . . . . . . . . . . . . . . . . . . 6 70 5.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5.5. Solution 5 . . . . . . . . . . . . . . . . . . . . . . . . 10 75 5.6. Merged solutions . . . . . . . . . . . . . . . . . . . . . 11 76 5.7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 11 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 Many Internet applications, including the widely used overlay 87 applications like peer-to-peer file sharing and video streaming, need 88 to access the resources which are available in several equivalent 89 replicas on different hosts, such as pieces of information or server 90 processes. The goal of Application-Layer Traffic Optimization (ALTO) 91 [I-D.ietf-alto-problem-statement] is to provide guidance to 92 applications, which have to select one or several hosts from a set of 93 candidates, which are able to provide the desired resource. is to 94 provide guidance to the applications, which have to select one or 95 several hosts from a set of candidates, which are able to provide the 96 desired resource. 98 This memo discusses the privacy and load issues which are important 99 for the benefits of ISP and P2P. Although these issues have been 100 extensively discussed on the ALTO mailing list, ALTO WG is still lack 101 of an ideal solution satisfying all the requirements. PROXIDOR, P4P 102 and other similar solutions all have their pros and cons regarding 103 all these aspects. This draft is to do a comparative study to 104 analyze and compare the privacy and workload of several existing 105 solutions, hence to provide guidance in order to improve, optimize 106 and employ the protocol. 108 1.1. Overview 110 The essential reason for risks in privacy consideration is that the 111 ISP and P2P can not trust each other fully. Network inefficiency 112 caused by the emerging P2P applications challenges the Internet 113 traffic controlled by ISP. Network providers have tried various 114 traffic control techniques including charging and rate throttling. 115 However, different P2P protocols may use different encryption and 116 dynamic ports to avoid being identified and message types are also 117 various. Furthermore, unilateral rate limiting by network providers 118 may significantly degrade P2P performance and be problematic with 119 consumers' needs. ISP will also face the legal suits from its 120 customers if it blocks the traffic. 122 ALTO proposes an ISP-P2P cooperating method to solve the network 123 traffic problem. The first issue for P2P applications to be 124 considered when using ALTO is whether ALTO can improve their 125 performance in a safe way. In ALTO's idea, P2P is guided by ISP in 126 peer selection. Some experiments, such as P4P field test, shows that 127 P2P performance can be improved in many aspects such as downloading 128 speed. But in terms of privacy, existing solutions have the problem 129 that they need some P2P operation information, to provide guidance 130 accordingly, and it is easy to figure out P2P traffic from this 131 information. If ISP wants to shape this traffic, P2P applications 132 can do nothing. On the other hand, though ISP has high pressure in 133 P2P traffic optimization, providing guidance means disclosing part of 134 their privacy information, which may lead to lots of attacks or other 135 risks. Moreover, providing new service introduces new costs to ISP. 136 Due to the huge number of peers, ISP servers need high capability and 137 optimal designation to provide ALTO service. Existing solutions such 138 as P4P, PROXIDOR have their strong points and weak points regarding 139 these aspects. 141 2. Terminology and Concepts 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 This document also reuses the concepts defined in 148 [I-D.ietf-alto-problem-statement] and [I-D.ietf-alto-reqs]. 150 3. Privacy consideration 152 As declared in ALTO problem statements 153 [I-D.ietf-alto-problem-statement], ISPs are required to provide their 154 intimate knowledge of their network topology to address the ALTO 155 problem. However, they usually think the revealed details of such 156 network information are confidential. On the other hand, the ALTO 157 client needs to provide some data that they think private in its 158 query to the ALTO sever, which could help to increase the accuracy 159 level in the replies. Thus, the privacy issues need to be considered 160 in ALTO protocol design. 162 3.1. ISP privacy 164 The security issue of ISPs concerns the potential risk of disclosing 165 network topology and provision information through peer locations and 166 the costs among peers. ISPs must evaluate how much information to 167 reveal and the resulted risks. For example, if an ISP reveals 168 extremely fine-grained information, it may be easier for attackers to 169 infer network topology information. ISPs should also take into 170 account that revealing overly coarse-grained information may not 171 provide much benefit to either themselves or applications. If ALTO 172 fails to improve the performance of P2P applications, it will not 173 become popular and be used by the P2P community. Even using 174 authentication or encrypt techniques, the ISP privacy can still be 175 gotten by P2P applications. It can resolve the security problem of 176 information transformation and security problem of server and client, 177 but not the problem of privacy disclosing. Thus in 179 [I-D.ietf-alto-reqs], the defined protocol is required to support 180 different levels of details in queries and responses, in order that 181 the provider f an ALTO service can be able to control the amount of 182 disclosed information (e.g., about the network topology). 184 3.2. P2P privacy 186 In some existing solutions, in order to obtain the ranking of 187 destination peers for a source peer, P2P applications need to send 188 the source and destination peer pairs to ALTO server. In this way, 189 ISP can easily infer the communication pattern so that P2P traffic 190 may suffer from rating or limiting actions from ISP. It is important 191 to note that there is no protocol mechanism requiring ALTO for P2P 192 applications. If P2P applications were required that the clients 193 send their operational information to the server, they may be 194 agitated by disclosing their information and ALTO service will be 195 discarded. Thus different levels of details in queries and responses 196 [I-D.ietf-alto-reqs] also need to be supported in requirement of user 197 privacy protection, in order to protect the privacy of users, to 198 ensure that the operators of ALTO servers and other users of the same 199 application cannot derive sensitive information. 201 4. Workload considerations 203 In the ALTO problem statements and requirements, the overload 204 protection and caching mechanism are required for ALTO protocol. 205 However, if overload happens frequently, even with protection 206 mechanism, it will cause bad performance of P2P applications and also 207 ISP network. 209 4.1. ISP load 211 The amount of peers an ALTO server needs to deal with could be 212 millions. Especially in some busy time, ALTO server may receive 213 millions of requests from the client at the same time. It causes 214 overload of servers without high capability. Therefore, the solution 215 should be highly scalable when the number of clients increases fast. 217 Assuming that there are n peers which are separated into t groups 218 (one PID per group) requesting ALTO service at one time, if there are 219 m candidates in average for each request peer, for PROXIDOR n times 220 sorting are needed and for P4P n times IP-PID mapping and t*t times 221 pDistance mapping are needed. Therefore, ALTO server should be 222 charge with a huge n of requests at the same time and also should be 223 deal with the continuously growing n. 225 4.2. P2P load 227 Using ALTO services, P2P applications should request and make use of 228 ALTO guidance for each peer selection. The cost is higher than 229 random peer selection. But comparing to some unilateral traffic 230 optimization methods, because P2P applications do not need to 231 estimate the network traffic, its cost is lower. 233 5. Solution space analysis 234 .---------. .----------. .---------. .-----------. 235 | IP | | cost of | | | | peer | 236 | | ->| | ->| ranking | ->| | 237 | mapping | | IP-pairs | | | |selection | 238 .---------. .----------. .---------. .-----------. 240 Figure 1. Basic process of P2P guidance 242 The goal of P2P guidance is to provide the ranking of the destination 243 peers. The basic process of P2P guidance can be summarized as 244 follows: first find the groups that the requested source and 245 destination peers belong to; then calculate or search the cost of 246 source and destination groups, maybe with consideration of some peer 247 attributes as the cost of source and destination peers; then sort the 248 costs and at last select peers according to the ranked costs. Here, 249 'group' is a set of peers defined by ISPs for the purpose of 250 aggregation under similar network characteristics. Most solutions 251 use this process with different group granularities. Finer gain of 252 group granularity, such as one peer per group, performs well but 253 costs more whereas coarse gain may lead to less effective guide. In 254 the second step, the cost between source and destination groups can 255 be prepared in advance or calculated on the fly. Due to the low 256 efficiency and poor performance of real time computation for huge 257 requests, the popular way is to calculate the cost of each peer pair/ 258 group pair in advance and maintains a back-end database that updates 259 at pre-determined intervals or sudden changes. Even though, for each 260 request the server has to do lookup from group pairs to their cost. 262 The ALTO server and client play different roles in these steps. In 263 different solutions, the server has different number of functions, 264 leading to different level of ISP and P2P privacy disclosing and 265 server load. Assuming that a function is only provided by ISP or 266 P2P, there will be five potential/existing solutions that support 267 ALTO service. 269 .---------. .----------. .---------. .-----------. 270 | IP | | cost of | | | | peer | 271 | | ->| | ->| ranking | ->| | 272 | mapping | | IP-pairs | | | |selection | 273 .---------. .----------. .---------. .-----------. 274 \-------------------------------------------------------/ 275 ALTO server 276 \-------------------------------------------------------/ 277 client 278 \--------------------------------------/ \----------/ ->PROXIDOR 279 ALTO server client 280 \-----------------------/ \------------------------/ ->P4P 281 ALTO server client 282 \--------/ \----------------------------------------/ 283 ALTO server client 285 Figure 2. Potential/existing solutions 287 5.1. Solution 1 289 An extreme way is that the ISP server charges all the process. In 290 this case, ISP directly forces P2P to select the peers it chooses. 291 Undoubtedly all the topology information can be kept in the server 292 side, but the P2P applications lose their independence and the ISP 293 server may be overloaded with too much work. This solution is not 294 reasonable. 296 5.2. Solution 2 298 Similarly, if P2P applications charge all the process with the primal 299 topology information, ISP may suffer from the risks caused by privacy 300 exposition. It is also unreasonable. 302 5.3. Solution 3 304 The acceptable solution is to find a strategy to divide the functions 305 to server and client. One solution is the server controls the first 306 three steps of the process and the client controls the last one. A 307 representative example is PROXIDOR. To use the PROXIDOR service, the 308 client generates a standard PROXIDOR query and sends to the PROXIDOR 309 server. The PROXIDOR server that receives a query will rank the 310 target IP address and then send back to the client. 312 PROXIDOR Server Client 313 | | 314 | V 315 | Retrieve candidate peer list 316 | | 317 | V 318 <--- |----Ask for ranking 319 | 320 Sort the list | 321 | 322 Send ranked list---- |---> | 323 | V 324 | Peer selection 325 | 327 Figure 3. Basic flow of PROXIDOR 329 The client can get the ranked destination peers directly. ISP's 330 privacy is kept because it is difficult to collect all costs of the 331 N*N IP pairs for an N IP network. It therefore has the advantage 332 that all operational information is kept in the ALTO server and is 333 not revealed to the ALTO client. But P2P applications should provide 334 all potential source and destination peer pairs. PROXIDOR requires 335 the exact destination peers per each source peer for sorting. ISPs 336 can be able to infer the communication patterns of a client from the 337 queries. P2P may be afraid of the privacy exposition so that not so 338 many P2P applications choose it. 340 In addition, similar to taking all functions in the server, this kind 341 of 3-1 partition solutions may also have the risk of overload. When 342 various P2P applications request ALTO services simultaneously at hot 343 time without caching, it is hard for the server to deal with the huge 344 requests. Even using caching, direct using IP for ranking requires 345 the cache mechanism to be design carefully. 347 5.4. Solution 4 349 Another solution is to distribute the first two functions to the 350 server and the others to the client, which is represented by P4P. In 351 P4P, the server controls the first two steps of the process. The 352 client queries the server and gets the group ID (PID) for peer, and 353 directly requests and obtains the cost/priority between source and 354 destination groups (pDistance). 356 iTracker Client 357 | | 358 | V 359 | Retrieve candidate peer list 360 | | 361 | V 362 <--- |----Ask for PIDs 363 Send PIDs---- |---> 364 | | 365 | V 366 <--- |----Ask for pDistance 367 Send pDistances----|---> | 368 | V 369 | 370 | Peer selection 371 | 372 (a) partial information 374 iTracker Client 375 | 376 <--- |----Ask for PID map 377 Send PID map---- |---> 378 | 379 <--- |----Ask for cost map 380 Send cost map----|---> 381 | 382 | Retrieve candidate peer list 383 | | 384 | V 385 | Peer selection 386 | 387 (b) full maps 389 Figure 4. Basic flow of P4P 391 PID may disclose some location information. This depends on the type 392 of PID, such as ASN. Though some services obtaining which AS an IP 393 belongs exist, they increase the possibility of privacy exposition. 394 The other indirect type may not have this problem. Through 395 collection all (M*M for an N IP into M groups) or most pDistance may 396 be obtained by P2P or other parties, a network topology may be 397 disclosed. Obviously, it is easier than PROXIDOR to infer a network 398 topology. However, if the reconstructed information can be obtained 399 by the other ways (e.g. traceroute), it does not need to be taken 400 into account much. 402 In P4P, Clients can potentially disclose private information to the 403 ALTO Service Portals if either PIDs are extremely fine-grained or 404 Network Location Identifiers are included directly in the query. One 405 possibility is that clients only retrieve the full set of PIDs (via 406 GetPIDMap) and pDistances (via GetpDistance). Without knowing which 407 one the source/destination is and how they link, it is hard for P2P 408 traffic to trace for each link. But it increases the risks of 409 disclosing ISP privacy on the other hand. In this way, other people 410 can easily access all pDistances to construct a topology on group 411 level. Granularity of group decides the probability that ISP and P2P 412 privacies expose to some extent. 414 Regarding the traffic load, it is obvious that clients charging 415 ranking step disperses the ranking cost from small numbers of servers 416 to large number of clients. Although the ranking cost is very low 417 for each peer, cost of millions of ranking altogether can not be 418 neglected and the delay issue should also be considered. Moreover, 419 because using group ID to request cost directly can reduce the 420 request time significantly, it can also reduce the server load. If 421 there are averagely X peers in a group, then the time of request may 422 decrease to 1/X or more. If ISP provides full network map and cost 423 map directly, the server's workload could be reduced more. Most time 424 it only needs to response to some timely requests. 426 5.5. Solution 5 428 In the case that P2P and ISP can not fully trust each other, another 429 possible way is to provide necessary ISP information for P2P guidance 430 without requesting P2P's operational information. Comparing with 431 other solutions in the figure, the characteristic of the last 432 solution is that the server controls the first step and the client 433 gets the costs of peer pairs, sorts the cost and then does the peer 434 selection only according to group IDs. In other solutions such as 435 2-2 partition, the group ID denoting Network Location Identifiers can 436 not represent cost relationship without a cost map. Instead, in this 437 solution the group ID for a peer could be used as the carrier which 438 also implies the cost to the other peer indirectly. 440 In section Section 5.4, 2-2 partition solutions such as P4P uses two 441 steps to guide P2P: obtaining PIDs for the source and destination 442 peer, and getting pDistance between the source PID and destination 443 PIDs. Incorporating the two steps in P4P, in 1-3 partition solution 444 ISP guides P2P through PID/group ID only. First ISP uses full set of 445 pDistance to construct the set of PIDs. These PIDs are only a set of 446 ruleless numbers, but from simple calculation with two PIDs the 447 pDistance between these two PID could be obtained. In this way, the 448 same performance as P4P could be obtained and the requests of getting 449 pDistance could also be avoided. ISP doesn't need P2P operational 450 details, which can reduce the risk of disclosing P2P privacy. Even 451 in the structured P2P network, some surrogate or transfer mechanisms 452 can be used to avoid source peer information being disclosed. 453 Although the ISP topology information can be inferred by the full 454 collection of PIDs as P4P, a correct computational function or driver 455 still need to be obtained additionally to calculate the corresponding 456 cost value. Moreover, the load on the ALTO server can be re-balanced 457 to ALTO server and ALTO clients together. 459 The methods for constructing PIDs from pDistances are various, which 460 can be freely adopted by ISP. The most appropriate PID type needs to 461 be further verified. 463 5.6. Merged solutions 465 The solutions discussed above are just simple classification. A 466 function may have different criterions and implementations in 467 different solutions. And a function may be charged not by ISP or P2P 468 alone. A cooperative way and a reliable third party can also be a 469 reasonable manager. A merged solution may satisfy different 470 requirements. For different P2P applications ISP can provide 471 different solutions according to their credits or other stipulations. 472 But this kind of merged solutions should be designed carefully to 473 make the protocol in phase. Furthermore, the merged solutions may 474 have the cons of the individual solutions. Of course, good 475 combinations can make them complementary to each other and improve 476 the advantages of protocol. However, providing multiple solutions 477 simultaneously will result in the increase of workload. Moreover, 478 aggregation of multiple solutions may introduce privacy concern of 479 these solutions which increase both ISP and P2P privacy risks in the 480 merged protocol. 482 5.7. Conclusion 484 In most cases, the more functions the ISP controls, the more cost the 485 ISP spends and the less privacy the ISP discloses, but more P2P 486 information is needed. On the other hand, if P2P controls more 487 functions, P2P information may not be open to ISP, but it means that 488 ISP may have to provide some sensitive information to P2P. In 489 conclusion, the protocol should provide at least the basic mechanisms 490 to deal with the privacy issue and it should be scaleable. The 491 requirements [I-D.ietf-alto-reqs] for supporting mutual 492 authentication of clients and servers are declared. But it is not 493 enough when clients prefer to avoid explicit authentication and have 494 privacy related to a network location basis. Currently ISP and P2P 495 can not trust each other completely for some reasons. P2P may want 496 much guidance which is sensitive to ISP. On the other hand, the 497 protection of ISP privacy may damage P2P privacy and lead to server 498 overload. Such conflictions should be solved, so there are 499 implications cannot be ignored. Such mechanisms should reach a 500 balance between the benefits and requirements of ISP and P2P. 502 6. Security Considerations 504 The security issues have been taken into account in design 505 considerations. An ALTO Server may optionally use authentication and 506 encryption to protect ALTO information. Note that it can only 507 prevent the information being disclosed on the path, but can not 508 prevent the information being redistributed by p2p applications. 509 This will be further discussed in other documents. 511 7. IANA Considerations 513 There is no IANA action required by this draft. 515 8. References 517 8.1. Normative References 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, March 1997. 522 8.2. Informative References 524 [I-D.ietf-alto-problem-statement] 525 Seedorf, J. and E. Burger, "Application-Layer Traffic 526 Optimization (ALTO) Problem Statement", 527 draft-ietf-alto-problem-statement-04 (work in progress), 528 September 2009. 530 [I-D.ietf-alto-reqs] 531 Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. 532 Yang, "Application-Layer Traffic Optimization (ALTO) 533 Requirements", draft-ietf-alto-reqs-01 (work in progress), 534 July 2009. 536 [I-D.akonjang-alto-proxidor] 537 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 538 Saucez, "The PROXIDOR Service", 539 draft-akonjang-alto-proxidor-00 (work in progress), 540 March 2009. 542 [I-D.wang-alto-p4p-specification] 543 Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, 544 "P4P Protocol Specification", 545 draft-wang-alto-p4p-specification-00 (work in progress), 546 March 2009. 548 [I-D.penno-alto-protocol] 549 Penno, R. and Y. Yang, "ALTO Protocol", 550 draft-penno-alto-protocol-03 (work in progress), 551 July 2009. 553 [I-D.song-alto-server-discovery] 554 Song, H., Tomsu, M., Garcia, G., Wang, Y., and V. Pascual, 555 "ALTO Service Discovery", 556 draft-song-alto-server-discovery-01 (work in progress), 557 July 2009. 559 Authors' Addresses 561 Yan Wang (editor) 562 Huawei 563 KuiKe Building, No.9 Xinxi Rd. Hai-Dian District 564 Beijing 100085 565 China 567 Email: wyan@huawei.com 569 Song Haibin 570 Huawei 571 Baixia Road No. 91 572 Nanjing, Jiangsu Province 210001 573 P.R.China 575 Phone: +86-25-84565867 576 Email: melodysong@huawei.com 578 Mach(Guoyi) Chen 579 Huawei 580 KuiKe Building, No.9 Xinxi Rd. Hai-Dian District 581 Beijing 100085 582 China 584 Email: mach@huawei.com