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