idnits 2.17.1 draft-kamei-p2p-experiments-japan-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2011) is 4795 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PRG S. Kamei 3 Internet-Draft NTT Corporation 4 Intended status: Informational T. Momose 5 Expires: September 5, 2011 Cisco Systems 6 T. Inoue 7 NTT Communications 8 March 4, 2011 10 ALTO-Like Activities and Experiments in P2P Network Experiment Council 11 draft-kamei-p2p-experiments-japan-05 13 Abstract 15 This document introduces experiments to clarify how ALTO-like 16 approach was effective to reduce network traffic made by a Council in 17 Japan to harmonize P2P technology with the infrastructure. And this 18 also provides some suggestions that might be useful for ALTO 19 architecture learned through our experiments. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 5, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Background in Japan . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. P2P traffic . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Impact on network infrastructure . . . . . . . . . . . . . 3 65 2.3. The object of P2P Network Experiment Council . . . . . . . 4 66 3. The details of the experiments . . . . . . . . . . . . . . . . 5 67 3.1. Dummy Node . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Hint Server ('08) . . . . . . . . . . . . . . . . . . . . . . 6 69 5. High-Level Trial Results . . . . . . . . . . . . . . . . . . . 11 70 5.1. Peer Selection with P2P . . . . . . . . . . . . . . . . . 11 71 5.2. Peer Selection with the Hint Server . . . . . . . . . . . 11 72 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. Next steps . . . . . . . . . . . . . . . . . . . . . . . . 12 74 6.2. Feedback to ALTO WG . . . . . . . . . . . . . . . . . . . 12 75 6.2.1. Hierarchical architecture for ALTO servers . . . . . . 12 76 6.2.2. Measurement mechanism . . . . . . . . . . . . . . . . 13 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 80 10. Informative References . . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 An overlay network, which is used by P2P and other applications, 86 offers the advantage of allowing flexible provision of services while 87 hiding the lower layer network. The downside is that inefficient 88 routes are often taken in the lower IP network, thereby increasing 89 the network load. Several proposals have been made to build an 90 overlay network that takes account of the information about the lower 91 layer network. Since the management of the Internet is highly 92 distributed, it is difficult to implement such proposals and thus 93 optimize a network without the cooperation of network providers. 95 Recently, the controversy between the overlay network and the network 96 providers have been rekindled. Under these circumstances, some 97 researchers have studied overlay network control technology that 98 takes account of the network topology information obtained from 99 network providers. 101 One of the activities concerning this issue has been made by the P2P 102 Network Experiment Council in Japan. This document reports on the 103 issues addressed and experiments being made by the council, focusing 104 on the experiments made from 2007 to 2008. 106 2. Background in Japan 108 2.1. P2P traffic 110 As of 2008, the world most popular P2P file sharing application 111 Bittorrent isn't widely deployed in Japan. Instead, other Japan 112 specific file sharing P2P applications such as Winny [1], Share [2], 113 PerfectDark, and so on, still occupy 40% of the Internet traffic in 114 Japan even though many those P2P users were arrested for sharing 115 illegal files with these P2P apps. 117 Each P2P file sharing application has their original protocol. 118 Therefore, it is more difficult to control one by one unlike 119 Bittorrent. 121 2.2. Impact on network infrastructure 123 One of the advantage of using P2P technology for content delivery is 124 that peers exchange content directly among themselves. This reduces 125 the load on servers. Also, P2P applications can reduce upstream 126 traffic from an original content server. This is significant that 127 the charge for upstream traffic is usually traffic-sensitive for 128 content delivery services, and it is not negligible. 130 It is also known that server cost could be reduced with P2P 131 technology. However, the story is quite different for network 132 providers. From the viewpoint of network providers, the traffic that 133 content servers generate has shifted to the edge network and the 134 amount of traffic has not necessarily been reduced. Another problem 135 for network providers that an extremely inefficient routing may be 136 selected has been raised. It is because overlay network systems are 137 configured without any regard to the structure of the lower layer 138 network or network geometry. 140 In some cases, traffic on the Internet used to be limited by the 141 capacity of servers. For those cases, the improvement in the 142 scalability of servers has made it likely that network resources will 143 be used up before server resources are. Using P2P applications 144 increases the volume of traffic per user remarkably. 146 Faced with increase in the load on network infrastructure, network 147 providers are compelled to take actions to overcome the sudden 148 increase in facilities' cost. Representative actions include placing 149 content in IXs or data centers, introducing bandwidth control, and 150 raising the access fees[3]. 152 In the future, video posting sites, which has been delivered using 153 client-server applications, may adopt P2P system. The increase in 154 traffic arising from such a shift will be a great threat to the 155 network. 157 2.3. The object of P2P Network Experiment Council 159 In order to reduce Internet traffic and encourage legitimate use of 160 P2P technologies, the Japanese government led to establish a new 161 council called P2P Network Experiment Council conjunction with 162 commercial P2P application vendors and ISPs in 2006. 164 Then the council had started to develop regulations that include 165 several guidelines such like an advance notice to restrict bandwidth 166 to heavy duty users. In accordance with the regulations, some ISPs 167 introduced solutions that reduce traffic caused by P2P file sharing 168 applications . 170 Besides this activity, the council also looked for new ways of 171 commercial use P2P applications under conjunction with ISPs, carrier, 172 contents providers and P2P system vendors. In this work, the council 173 had experiments that introduced ALTO-like system and observed how the 174 traffic was reduced by redirecting to proper peers on the real 175 Internet in Japan. 177 This memo describes the overview of the experiments. 179 3. The details of the experiments 181 The council has already learned that the server cost could be reduced 182 with using P2P technology for contents delivering by investigating 183 data offered by the members of the council. For example, the data 184 brought by the vendors shows as follows: 186 90% of traffic was reduced with UG Live by Utagoe Inc[4]. 188 The costs of delivering to tens of thousand subscribers was 189 reduced to 1/5 with BBbroadcast with TV Bank Corp.[5] 191 On the other hand, these reduced server costs may affect network 192 load. One of the goals of our experiments are to visualize the 193 impacts and propose an architecture to reduce network load caused by 194 these new technologies. 196 To satisfy the above goals, the framework to be proposed should be 197 well generalized as possible that doesn't rely specific P2P 198 application behaviors because multi P2P application vendors join 199 these experiments. In addition, the traffic should be captured 200 beyond multi ISPs. 202 3.1. Dummy Node 204 As mentioned before, while the effect of delivery using P2P 205 technology on reducing the traffic and the load on servers is well 206 known, traffic behavior in the inter-ISP is not known. In Japan, 207 there is a backbone traffic report cooperated with ISPs and IXes [6]. 208 However, this measurement requires to capture packets on subscribers 209 line to know end user's activity. It is not realistic to measure the 210 behavior of P2P applications at user terminals connected to the 211 Internet because that would require a large-scale arrangement for 212 measurement, such as using Deep Packet Inspection (DPI) on aggregated 213 lines. 215 To solve these problems, we put several nodes called 'dummy nodes' in 216 the ISP's networks. The dummy nodes emulate an end user's PC and P2P 217 applications are running on the nodes. 219 By introducing dummy nodes, we can observe and evaluate how much P2P 220 applications have affected networks by measuring the traffic on dummy 221 nodes. Since this method can't measure every subscriber's traffic, 222 the accuracy would be less than other methods. But this make it 223 possible to adapt to situations many different P2P applications 224 coexist on a network. We can say this is suitable for these 225 experiments. 227 A dummy node consists of Intel PC server, Linux(CentOS), VMWare and 228 Windows XP works on VMWare. With this configuration, all packets can 229 be captured without any impacts to the network, nodes and application 230 behaviors. And it enable us to use different P2P applications for 231 windows and evaluate them generally. 233 To see behaviors of the node, incoming and outgoing packets are 234 captured on Linux because every packets are transmitted through it. 235 In these experiments, we captured source/destination address, port 236 number, amount of traffic and start/end time to see flow information. 238 60 Dummy nodes are put on access networks that are closest subscriber 239 as possible in different 40 networks. 241 +----------------------+ 242 |+--------------------+| 243 ||+------------------+|| 244 ||| P2P Application ||| 245 ||| WindowsXP ||| 246 ||| +--+ ||| 247 ||+--------|N |------+|| 248 || VMware |e | || 249 |+---------|t |-------+| 250 | Linux |IF| capture| 251 +----------| |--------+ 252 +--+ 254 Dummy nodes 256 Figure 1 258 4. Hint Server ('08) 260 In Japan, bottleneck in IP networks will shift from access networks 261 to backbone networks and equipments, such as bandwidth between ISPs 262 and capacity in IXs, since FTTH has rapidly spread all over Japan. 263 Under this situation, the Council proposed a less restrictive and 264 more flexible cooperation between ISPs than existent P4P experiments 265 [7]. The proposed method consists of the following elements: (1) P2P 266 clients, (2) P2P control servers, and (3) a peer selection hint 267 server, and a Hint Server. (1) and (2) are existing systems but 268 whether (2) exists depends on each application. (3) is a server that 269 provides a hint as to the selection of a peer, and plays a role 270 equivalent to that of ALTO Server. Note that this proposal was based 271 on results of experiments using dummy nodes. The results showed that 272 it was possible to reduce unnecessary traffic that flows across the 273 boundaries of geographical districts or ISPs through providing 274 information about the physical network to P2P applications. 276 When a peer joins the network, it registers its location information 277 (IP address) and supplementary information (line speed, etc.) with 278 the Hint Server. The Hint Server makes a mapping of the new peer 279 (P2P client) based on network topology information obtained from the 280 ISP, generates a routing table in which peers are listed in the order 281 of priority for selection, and returns the table to the peer. 283 If all information can be made public, the above procedure can 284 produce a result which is close to overall optimization. However, 285 some information held by ISPs can often be confidential. Besides, in 286 some cases, the volume of calculation required to process all 287 information can be excessive. To avoid these problems, it is planned 288 to conduct experiments with a limited set of functions, analyze 289 experiments results, and gradually expand the scope of optimization. 291 A control mechanism that makes use of all possible information is 292 difficult not only technically but also difficulties to achieve 293 coordination among providers. In consideration of these 294 difficulties, the council has been limiting the implementation and 295 experiments to the following scope since 2006. 297 Figure 2 shows an outline of the hint server. 299 +---------+ GetLocation +-------------GeoIP DB Server---------+ 300 | | +-----------+ | +----------+ +-----------+ | 301 | |--|IP Address |-->| | GeoIP DB | |Quagga etc | | 302 | | +-----------+ | +----------+ +-----------+ | 303 | | | +-------------+ +----------------+ | 304 | | +-----------+ | | District | | Routing | | 305 | |--|AS Code: |---| | information | |information(DGP)| | 306 | | |Regional | | | | | | | 307 |P2P Peers| |Information| | | Range of | |AS Code(origin) | | 308 | or | +-----------+ | | IP address | | | | 309 | Contro| | | +-------------+ +----------------+ | 310 | Server | +-------------------------------------+ 311 | | | ^ 312 | | PeerSelection v | 313 | | +-----------+ +--------------------------------------+ 314 | |--|IP Address |-->| +--Priority Node Selection System--+ | 315 | | | List | | | | | 316 | | +-----------+ | | Peer candidate ranking | | 317 | | +-----------+ | | | | 318 | |--| Ranking |-->| +----------------------------------+ | 319 | | +-----------+ +--------------------------------------+ 320 +---------+ 322 Peer selection hint server 324 Figure 2 326 The network information used by the Hint Server is not information 327 solicited from individual ISPs but the AS number and district 328 information, which are more or less already public. Routing tables 329 are not generated. Instead, peers within the same ISP or the same 330 district are selected with higher priority in order to confine 331 traffic to within the same ISP or the same district. 333 When the Hint Server receives an IP address, it returns its attribute 334 information, to achieve the above. A peer can select a peer based on 335 the returned information. This operation is called GetLocation. 336 However, in preparation for the time when it becomes necessary to 337 hide topology information, an interface is provided through which a 338 priority order is returned in response to an input of a list of 339 candidate peers. This operation is called PeerSelection. 341 Although the priority node is selected based on the criterion that it 342 is within the same ISP or the same district, this type of selection 343 is not very effective if the number of participating peers is small. 344 Table 1 shows ratio of peers within the same AS or the same 345 prefecture calculated from the distribution of ASs and prefectures in 346 the IP address space from one-day data on a Winny network. 348 +--------------------+--------+ 349 | Conditions | ratio | 350 +--------------------+--------+ 351 | AS matches | 6.70% | 352 | Prefecture matches | 12.76% | 353 | Both match | 2.09% | 354 | Neither match | 78.45% | 355 +--------------------+--------+ 357 Table 1: AS and prefecture distributions 359 Since, in addition to the above, the presence/absence of content 360 affects the result, the control of selecting a peer within the same 361 district may be inadequate. Therefore, it is necessary to introduce 362 the weight of a continuous quantity that reflects the physical 363 distance or the AS path length as an indicator of the proximity of 364 the areas involved. 366 In consideration of the above, the following two measures are used 367 for the evaluation of proximity between peers in a Hint Server. 369 o AS path length (distance between ISPs) 371 AS path length calculated from BGP full routes. Since a full 372 routing table retrieved at an ISP can show only a best path, it 373 may not get an accurate length if the AS hop of both ISPs is too 374 large. To avoid this, we use multiple BGP information gotten at 375 different ISPs and combine them. Based on this concept, we used 376 BGP routing information's offered by three ISPs operated by big 377 telecommunication couriers and made a topology tree. Then it 378 enables to calculate the shortest path between given two ASes. 380 o Geographical distance 382 Distances between peers are measured using physical distance of 383 prefectural capitals that target peers belong to. The distance 384 between prefectural capitals is used to calculate physical 385 distance. Distances between prefectural capitals are sorted into 386 ascending order, and then into bands, with weights 1 to 15 387 assigned to them so that there are a more or less equal number of 388 "capital pairs" in each band. If either of their location is 389 indefinite, distance is equal to 15 and, if they are in the same 390 prefecture, distance is equal to 0. 392 Evaluation of distances between peers showed that the distribution 393 of distances was almost uniform when distances between peers are 394 normalized. This result suggests that using normalized distances 395 expands the area where the control by a Hint Server is effective. 397 An example of the request and the response 399 o Request 401 POST /PeerSelection HTTP/1.1 402 Host: ServerName 403 User-Agent: ClientName 404 Content-Type: text/plain; charset=utf-8 406 v=Version number 407 [application=Application identifier] 408 ip=IP address of physical interface 409 port=Port number of physical interface 410 [nat={no|upnp|unknown}] 411 [nat_ip=Global IP address using UPnP] 412 [nat_port= Global port number using UPnP] 413 [trans_id=transcation ID] 414 [pt=Flag of port type] 415 [ub=upload bandwidth] 416 [db=download bandwidth] 418 o Response 420 HTTP/1.1 200 OK 421 Date: Timestamp 422 Content-Type: text/plain; charset=utf-8 423 Cache-control: max-age=max age 424 Connection: close 426 v=Version number 427 ttl=ttl 428 server=hint server name 429 ... 430 trans_id=transaction ID 431 pt=Flag of port type 432 client_ip=Peer IP address observed from server 433 client_port=Peer port number observed from server 434 numpeers=number of respond peer 435 n=[src address] dst address / cost / option 437 5. High-Level Trial Results 439 5.1. Peer Selection with P2P 441 Table 2 shows the result of the analysis of communication in a node 442 of an ISP installed in Tokyo, as an example of measurement results. 444 +-----------------------------------------+------------+------------+ 445 | Conditions | Experiment | Experiment | 446 | | 1 | 2 | 447 +-----------------------------------------+------------+------------+ 448 | *Peers selected within the same ISP | 22% | 29% | 449 | *Peers selected within the same | 19% | 23% | 450 | district | | | 451 | *Peers selected within the same | 5% | 7% | 452 | district and the same ISP | | | 453 +-----------------------------------------+------------+------------+ 455 Table 2: Percentage of communication within the same ISP 457 The table shows that the probability of communication with peers in 458 the same ISP is proportional to the number of population and the 459 share of the ISP in each district. The data show that peers were 460 selected at random. Note that the vendor of a P2P application used 461 in these experiments explained that the mechanism of selection a peer 462 using network information can be implemented. However, peer 463 selection is normally based on past information because users often 464 cannot actually perceive the effect of using network information. 466 5.2. Peer Selection with the Hint Server 468 Since the main objective of these experiments was to verify the 469 operations of the Hint Server and P2P applications, the degree to 470 which traffic in the network was actually reduced was not evaluated. 471 However, the distances between a dummy node and a peer were obtained 472 from data on the dummy nodes. An examination of the distances 473 between a dummy node and a peer revealed that mean value of distance 474 after the Hint Server was introduced was reduced by 10% and that 95% 475 value of that was reduced by 5%. 477 6. Considerations 479 We clarified followings throughout our experiments. 481 1. Dispersed dummy nodes can figure out the behavior of peers and 482 traffic between inter-ISP networks, which peers are selected by 483 each peer. Therefore it proves that the importance of peer 484 selection control mechanism proposed in ALTO. 486 2. Using our peer selection control mechanism, called hint server, 487 could achieve significant differences. Our hint server can lead 488 each peer to select nearer peer. 490 In the experimental result of peer selection control, it is smaller 491 in intra-ISP traffic than other experiments[8] We think that it is 492 because there are smaller peers in each area of traffic control. 493 When there are many peers in one ISP, it is easy to select peers in 494 the same ISP. However, when there are small peers in one ISP, it is 495 difficult to select peers in the same ISP. In the situation of our 496 experiments, there are many ISPs of peers belonging, and there are 497 relatively smaller peers exist in same ISP. 499 Moreover, we didn't force P2P vendors to limit their implementation 500 policy, therefore we can observe differences how each implementations 501 weigh the information from the hint servers. Especially, in tree 502 overlay topology P2P applications, such mechanism is very effective, 503 on the other hand, in mesh overlay system, less effective. 505 6.1. Next steps 507 The experiments are on going as of 2011. Current experiments in 508 2011, we've changed the communication protocol to hint servers to 509 ALTO based because it is nearly standardized. In our implementation, 510 PIDs and the value of cost are mapped to ISP subnets, and ISP 511 distance respectively. We also implement services for compatibility 512 required by ALTO such as Service Capability and Map Services. But 513 the Endpoint Cost Service is mainly used because of backward 514 compatibility of our experiments. 516 We also study hierarchical hint server structure, in order to control 517 in coarse inter-ISPs and in detail intra-ISP. It is also effective 518 for limiting the area of information disclose. 520 6.2. Feedback to ALTO WG 522 This section describes what the authors learned with these 523 experiments would be useful for the ALTO WG. 525 6.2.1. Hierarchical architecture for ALTO servers 527 In our experiments, we present the possibility of traffic control 528 among multi-ISPs and multi-P2P applications using ALTO mechanism. On 529 the other hand, we found several problems in ISP operations to adapt 530 the mechanism. One is the granularity of network information. Among 531 inter-ISP area, it is relatively easy to treat information for public 532 purpose using BGP full route. On the other hand, among intra-ISP 533 area, it may be difficult to disclose private information of each 534 ISP. [9] propose some modification for ALTO protocol in order to hide 535 ISP information. We propose hierarchical structures. From the 536 viewpoint of cooperation between ISPs, fine-grained information is 537 not necessarily required and moreover it is difficult to exchange the 538 fine-grained information between ISPs. Considering this situation, 539 the authors use only coarse-grained information to control backbone 540 traffic in the experiments this year, though demand of controlling 541 traffic within an ISP using fine-grained information will arise in 542 the near future. Therefore it led us that introducing hierarchical 543 structure into ALTO is necessary to cope with both situations. 544 Actually, the authors plan to adapt a hierarchical control mechanism 545 in the next steps, which include the following two steps. 547 o In the first step, coarse-grained information about whole the 548 network is used to select ISPs. 550 o Next, fine-grained information within the ISP is used to select a 551 peer. 553 6.2.2. Measurement mechanism 555 In the experiments, there were two difficulties as follows: 557 o Evaluating effect of introducing a Hint Server was difficult, 558 since P2P applications had their own measurement mechanisms. 560 o How to treat priority orders of peers suggested by a Hint Server 561 could not be predetermined for P2P applications. 563 From these experiences, the authors consider that clarifying 564 requirements about measurement mechanisms for P2P applications are 565 necessary also in ALTO. 567 7. Security Considerations 569 This document does not propose any kind of protocol, practice or 570 standard. 572 8. IANA Considerations 574 No need to describe any request regarding number assignment. 576 9. Acknowledgments 578 Thanks to strong support by MIC (Ministry of Internal Affairs and 579 Communications of Japanese government), the council was established. 580 These experiments were performed under cooperation among P2P Network 581 Experiment Council members, and DREAMBOAT co.,ltd., Bitmedia Inc., 582 Utagoe. Inc. and Toyama IX have especially supported analyses of the 583 experiments. The authors appreciate Tohru Asami, Hiroshi Esaki and 584 Tatsuya Yamshita for their constructive comments. 586 10. Informative References 588 [1] "Winny on Wikipedia", . 590 [2] "Share on Wikipedia", 591 . 593 [3] Taniwaki, "Broadband Competition Policy in Japan", 2008, 594 . 596 [4] Utagoe Inc., "UGLive technology introduction", 597 http://www.utagoe.com/en/technology/grid/live/index.html, March, 598 2011. 600 [5] TVBank, "Live Delivery using `BB Broadcast'Achieving 96% Saving 601 in Traffic!", http:.wwww.tv-bank.com/jp/20081031.html, 2008 (in 602 Japanese). 604 [6] Cho, Fukuda, Esaki, and Kato, "The Impact and Implications of 605 the Growth in Residential User-to-User Traffic", SIGCOMM2006, 606 pp207-218, Pisa, Italy, September 2006. 608 [7] Open P4P, "P4P Field Tests: Yale-Pando-Verizon", 609 http://www.openp4p.net/front/fieldests, 2009. 611 [8] "RFC5632: Comcast's ISP Experiences in a Proactive Network 612 Provider Participation for P2P (P4P) Technical Trial", September 613 2009. 615 [9] "ALTO H12,draft-kiesel-alto-h12-02 (work in progress)", March 616 2010. 618 Authors' Addresses 620 Satoshi Kamei 621 NTT Service Integration Laboratories 622 3-9-11, Midori-cho 623 Musashino-shi, Tokyo 180-8585 624 JP 626 Phone: +81-422-59-6942 627 Email: kamei.satoshi@lab.ntt.co.jp 629 Tsuyoshi Momose 630 Cisco Systems G.K. 631 2-1-1 Nishi-Shinjuku 632 Shinjuku-ku, Tokyo 163-0409 633 JP 635 Phone: +81-3-5324-4154 636 Email: tmomose@cisco.com 638 Takeshi Inoue 639 NTT Communications 640 3-4-1, Shibaura 641 Minato-ku, Tokyo 108-8118 642 JP 644 Phone: +81-3-6733-7177 645 Email: inoue@jp.ntt.net