idnits 2.17.1 draft-kamei-p2p-experiments-japan-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 : ---------------------------------------------------------------------------- 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 (October 19, 2009) is 5303 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 ALTO WG S. Kamei 3 Internet-Draft NTT Corporation 4 Intended status: Informational T. Momose 5 Expires: April 22, 2010 Cisco Systems 6 T. Inoue 7 T. Nishitani 8 NTT Communications 9 October 19, 2009 11 ALTO-Like Activities and Experiments in P2P Network Experiment Council 12 draft-kamei-p2p-experiments-japan-00 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 22, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document provides some suggestions about ALTO architecture 51 through experiments made by P2P Network Experiment Council in Japan. 52 This document also introduces experiments made by the Council in 53 Japan to harmonize P2P technology with the infrastructure. 54 Specifically, this document describes Hint Server technology, which 55 is similar to ALTO technology. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Background in Japan . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. P2P traffic . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Impact on network infrastructure . . . . . . . . . . . . . 4 63 3. The object of P2P Network Experiment Council . . . . . . . . . 5 64 4. Activity in P2P Network Experiment Council . . . . . . . . . . 6 65 4.1. Dummy Node . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Hint Server ('08) . . . . . . . . . . . . . . . . . . . . 6 67 4.3. Difference between ALTO and Hint Server technology . . . . 9 68 5. High-Level Trial Results . . . . . . . . . . . . . . . . . . . 11 69 5.1. Peer Selection with P2P . . . . . . . . . . . . . . . . . 11 70 5.2. Peer Selection with the Hint Server . . . . . . . . . . . 11 71 6. Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7. Feedback to ALTO WG . . . . . . . . . . . . . . . . . . . . . 12 73 7.1. Harmonizing a Hint Server with ALTO . . . . . . . . . . . 12 74 7.2. Measurement mechanism . . . . . . . . . . . . . . . . . . 13 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 78 11. Informative References . . . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 An overlay network, which is used by P2P and other applications, 84 offers the advantage of allowing flexible provision of services while 85 hiding the lower layer network. The downside is that inefficient 86 routes are often taken in the lower IP network, thereby increasing 87 the network load. Several proposals have been made to build an 88 overlay network that takes account of the information about the lower 89 layer network. Since the management of the Internet is highly 90 distributed, it is difficult to implement such proposals and thus 91 optimize a network without the cooperation of network providers. 93 Recently, the controversy between the overlay network and the network 94 providers have been rekindled. Under these circumstances, some 95 researchers have studied overlay network control technology that 96 takes account of the network topology information obtained from 97 network providers. 99 One of activities concerning this issue has been made by the P2P 100 Network Experiment Council in Japan. This document reports on the 101 issues addressed and experiments being made by the P2P Network 102 Experiment Council in Japan, focusing on the experiments made from 103 2007 to 2008. 105 2. Background in Japan 107 2.1. P2P traffic 109 In Japan, the major of P2P applications used today is Winny. P2P 110 applications are the sources of a considerable volume of traffic. 111 Recent study [1] showed more than 60% of Internet traffic in Japan is 112 generated by P2P applications. 114 Although traffic from P2P applications increased much more rapidly 115 than traffic from client-server-type web applications, it has leveled 116 off lately as a result of legal restrictions advocated by copyright 117 management organizations and traffic control implemented by ISPs. 118 According to [2], video delivery sites using Flash has again 119 increased volume of web traffic per user, making P2P traffic 120 relatively less conspicuous than before. 122 Consequently, some believe that P2P traffic is no longer a threat to 123 the infrastructure. P2P applications, however, rapidly became widely 124 used to get around the limit of the servers' capacity, which was 125 caused by the increase in demand for delivery of music files. It is 126 likely that the traffic of client-server video delivery will shift to 127 P2P delivery. 129 In fact, some P2P content delivery systems solve copyright issues, 130 for example, Sharecast, Ocean-Grid, TVBand, and so on. The 131 transmission of President Obama's Inaugural Address, which is the 132 largest-scale transmission of content in recent history, was mostly 133 of the client-server type. However, the delivery by CNN used a P2P 134 plug-in made by Octoshape. Traffic data observed by Illinois 135 University revealed unique traffic patterns that the upstream traffic 136 exceeded the downstream traffic. 138 2.2. Impact on network infrastructure 140 One of advantage of using P2P technology for content delivery is that 141 peers exchange content directly among themselves. This reduces the 142 physical load on servers . Also, P2P applications can reduce 143 upstream traffic from an original content server. This is 144 significant that the charge for upstream traffic is usually traffic- 145 sensitive for content delivery services, and it is not negligible. 147 Actually, the volume of traffic sent by the content server in 148 TVBank's P2P content delivery was reduced by a maximum of 96% 149 compared with the volume of traffic received by users [3]. This 150 indicates the great cost-saving of P2P technology from the 151 perspectives of the load on server hardware and the traffic relaying 152 cost of data centers. However, the story is quite different for 153 network providers. From viewpoint of network providers, the traffic 154 that content servers generate has shifted to the edge network and the 155 amount of traffic has not necessarily been reduced. Another problem 156 for network providers that an extremely inefficient routing may be 157 selected has been raised. It is because overlay network systems are 158 configured without any regard to the structure of the lower layer 159 network or network geometry. 161 Traffic on the Internet used to be limited by the capacity of 162 servers. Today the improvement in the scalability of servers has 163 made it likely that network resources will be used up before server 164 resources are. Using P2P applications increases the volume of 165 traffic per user remarkably. 167 Faced with increase in the load on network infrastructure, network 168 providers are compelled to take actions to overcome the sudden 169 increase in facilities' cost. Representative actions include placing 170 content in IXs or data centers, introducing bandwidth control, and 171 raising the access fees [2]. 173 In the future, video posting sites, which has been delivered using 174 client-server applications, may adopt P2P system. The increase in 175 traffic arising from such a shift will be a great threat to the 176 network. 178 3. The object of P2P Network Experiment Council 180 The Japanese Ministry of Internal Affairs and Communications, which 181 has jurisdiction over information and communication systems in Japan, 182 held meetings of an advisory panel on network neutrality from 2006 to 183 2007 in order to study issues related to next generation networks, 184 such as how to ensure fairness in the use of networks and how to 185 define fairness in cost burden. The panel took an interest in P2P 186 technology as a solution to the impending traffic saturation in the 187 backbone network resulting from the rapid expansion of broadband 188 access in Japan, and formed a "Working Group on the P2P Network", 189 which carried out an intensive study of P2P networks. 191 The Working Group reported that it is necessary to undertake the 192 following four activities, which are intended to encourage the 193 government to adopt relevant policies [4]: 195 o Formulate guidelines to be self-imposed by the industry on P2P 196 file delivery applications, 198 o Promote feasibility tests of P2P networks, 200 o Study the current state of traffic control and promote the sharing 201 of information, 203 o Hold working group meetings on traffic control. 205 The first two proposals led to the establishment of the P2P Network 206 Experiment Council supported by the Japanese Ministry of Internal 207 Affairs and Communications [5]. The Council, with membership from 208 P2P delivery providers, content holders, and network providers, began 209 a variety of delivery experiments, which were expected to strengthen 210 cooperative control between different layers. In contrast to P4P, 211 which takes a relatively top-down approach of adopting architecture 212 based on a proposal from a university, the Council is characterized 213 by its bottom-up approach. The aim of establishing the Council has 214 been described as follows. 216 The rapid growth of broadband access enables content delivery 217 system to deliver high-quality and high-volume videos securely and 218 efficiently. Although P2P technology is an effective technology 219 for this requirement, it still has some issues to be coped with. 220 Therefore, the "P2P Network Experiment Council" was established 221 with the support of the Japanese Ministry of Internal Affairs and 222 Communications with its secretariat set up within the Foundation 223 for MultiMedia Communications (FMMC) in order to formulate 224 guidelines for providers and conduct feasibility tests so that 225 users can receive video delivery services safely. 227 The activities of the P2P Network Experiment Council can be 228 classified into two categories. The first is activities to formulate 229 guidelines for the promotion of the commercial use of P2P technology. 230 These will enable users to use P2P technology safely, and providers 231 to have clear rules they must observe. The other is feasibility 232 tests of P2P technology. The next section mainly reports on 233 experiments conducted from 2007 to 2008. 235 4. Activity in P2P Network Experiment Council 237 4.1. Dummy Node 239 While the effect of delivery using P2P technology on reducing the 240 traffic and the load on servers is well known, traffic behavior in 241 the Internet is not known. However, it is not realistic to measure 242 the behavior of P2P applications at user terminals connected to the 243 Internet because that would require a large-scale arrangement for 244 measurement, such as using Deep Packet Inspection (DPI) on aggregated 245 lines. To solve this problem, dummy nodes have been introduced. 246 Dummy nodes have been settled in the Internet and P2P applications 247 have been installed on these nodes. Dummy nodes enable us to measure 248 and analyze communication among peers. 250 Specifically, Linux servers were installed at 40 sites of some ISPs, 251 and a virtual Windows environment was installed on the servers. P2P 252 applications which were target to measure were running on that 253 environment, and packets were captured by a Linux program to obtain 254 information on communication destinations and communication 255 frequencies. 257 4.2. Hint Server ('08) 259 In Japan, bottleneck in IP networks will shift from access networks 260 to backbone networks and equipments, such as bandwidth between ISPs 261 and capacity in IXs, since FTTH has rapidly spread all over Japan. 262 Under this situation. the Council proposed a less restrictive and 263 more flexible cooperation between ISPs than ALTO. The proposed 264 method consists of the following elements: (1) P2P clients, (2) P2P 265 control servers, and (3) a peer selection hint server, and a Hint 266 Server. (1) and (2) are existing systems but whether (2) exists 267 depends on each application. (3) is a server that provides a hint as 268 to the selection of a peer, and plays a role equivalent to that of 269 iTracker in P4P's study. Note that this proposal was based on 270 results of experiments using dummy nodes. The results showed that it 271 was possible to reduce unnecessary traffic that flows across the 272 boundaries of districts or ISPs through providing information about 273 the physical network to P2P applications. 275 When a peer joins the network, it registers its location information 276 (IP address) and supplementary information (line speed, etc.) with 277 the Hint Server. The Hint Server makes a mapping of the new peer 278 (P2P client) based on network topology information obtained from the 279 ISP, generates a routing table in which peers are listed in the order 280 of priority for selection, and returns the table to the peer. 282 If all information can be made public, the above procedure can 283 produce a result which is close to overall optimization. However, 284 some information held by ISPs can often be confidential. Besides, in 285 some cases, the volume of calculation required to process all 286 information can be excessive. To avoid these problems, it is planned 287 to conduct experiments with a limited set of functions, analyze 288 experiment results, and gradually expand the scope of optimization. 290 A control mechanism that makes use of all possible information is 291 difficult not only technically but also because it is difficult to 292 achieve coordination among providers. In consideration of these 293 difficulties, the P2P Network Experiment Council has been limiting 294 the implementation and experiments to the following scope since 2006. 296 Figure 1 shows an outline of the hint server. 298 +---------+ GetLocation +-------------GeoIP DB Server---------+ 299 | | +-----------+ | +----------+ +-----------+ | 300 | |--|IP Address |-->| | GeoIP DB | |Quagga etc | | 301 | | +-----------+ | +----------+ +-----------+ | 302 | | | +-------------+ +----------------+ | 303 | | +-----------+ | | District | | Routing | | 304 | |--|AS Code: |---| | information | |information(DGP)| | 305 | | |Regional | | | | | | | 306 |P2P Peers| |Information| | | Range of | |AS Code(origin) | | 307 | or | +-----------+ | | IP address | | | | 308 | Contro| | | +-------------+ +----------------+ | 309 | Server | +-------------------------------------+ 310 | | | ^ 311 | | PeerSelection v | 312 | | +-----------+ +--------------------------------------+ 313 | |--|IP Address |-->| +--Prioryty Node Selection System--+ | 314 | | | List | | | | | 315 | | +-----------+ | | Peer candidate ranking | | 316 | | +-----------+ | | | | 317 | |--| Ranking |-->| +----------------------------------+ | 318 | | +-----------+ +--------------------------------------+ 319 +---------+ 321 Figure 1 323 The network information used by the Hint Server is not information 324 solicited from individual ISPs but the AS number and district 325 information, which are more or less already public. Routing tables 326 are not generated. Instead, peers within the same ISP or the same 327 district are selected with higher priority in order to confine 328 traffic to within the same ISP or the same district. 330 When the Hint Server receives an IP address, it returns its attribute 331 information, to achieve the above. A peer can select a peer based on 332 the returned information. This operation is called GetLocation. 333 However, in preparation for the time when it becomes necessary to 334 hide topology information, an interface is provided through which a 335 priority order is returned in response to an input of a list of 336 candidate peers. This operation is called PeerSelection. 338 Although the priority node is selected based on the criterion that it 339 is within the same ISP or the same district, this type of selection 340 is not very effective if the number of participating peers is small. 341 Table 1 shows ratio of peers within the same AS or the same 342 prefecture calculated from the distribution of ASs and prefectures in 343 the IP address space from one-day data on a Winny network. 345 +--------------------+--------+ 346 | Conditions | ratio | 347 +--------------------+--------+ 348 | AS matches | 6.70% | 349 | Prefecture matches | 12.76% | 350 | Both match | 2.09% | 351 | Neither match | 78.45% | 352 +--------------------+--------+ 354 Table 1: AS and prefecture distributions 356 Since, in addition to the above, the presence/absence of content 357 affects the result, the control of selecting a peer within the same 358 district may be inadequate. Therefore, it is necessary to introduce 359 the weight of a continuous quantity that reflects the physical 360 distance or the AS path length as an indicator of the proximity of 361 the areas involved. 363 In consideration of the above, the following two measures are used 364 for the evaluation of proximity between peers in a Hint Server. 366 o AS path length (distance between ISPs) 368 Distances between peers are weighted using the degree of paths' 369 matching from an origin AS to ASs that target peers belong to. 370 The degree of paths' matching means ratio of common paths from an 371 origin AS (for example, 4/6 between A-B-C, and A-B-D, 6/8 between 372 A-B-C-D and A-B-C-E). In this year, the OCN is used as an origin 373 AS. Distance is calculated as int((1.0- degree of matching of AS 374 paths)*15). Distance is 15 if either of AS path is indefinite, 375 and is 0 if there is a perfect match. 377 o Physical distance 379 Distances between peers are measured using physical distance of 380 prefectural capitals that target peers belong to. The distance 381 between prefectural capitals is used to calculate physical 382 distance. Distances between prefectural capitals are sorted into 383 ascending order, and then into bands, with weights 1 to 15 384 assigned to them so that there are a more or less equal number of 385 "capital pairs" in each band. If either of their location is 386 indefinite, distance is equal to 15 and, if they are in the same 387 prefecture, distance is equal to 0. 389 Evaluation of distances between peers showed that the distribution 390 of distances was almost uniform when distances between peers are 391 normalized. This result suggests that using normalized distances 392 expands the area where the control by a Hint Server is effective. 394 4.3. Difference between ALTO and Hint Server technology 396 To explain difference between ALTO and Hint Server technology, 397 architecture proposed by ALTO is described. P4P aims to control 398 traffic in such a way that traffic is confined within the same 399 district or AS. As shown in Figure 2, iTracker provides an interface 400 for P2P content delivery using appTracker and peers in BitTorrent. 401 This arrangement provides a framework for efficient control based on 402 network information. 404 In this framework, it is proposed that ISPs and applications share 405 the following types of information through iTracker: 407 o Info: information about peers within an ISP 409 - ASID AS number 411 - Group number of PID node (peer) 413 - LOC: virtual and geographical coordinates 415 o Policy: information about policy on usage specified by an ISP 416 - Ratio between outgoing traffic and incoming traffic that flows 417 between domains 419 - Desirable daily traffic variation pattern on a link 421 - Specifications about relations between peer groups (PID) 423 o Capability: information about the capability of an ISP 425 - Information about usable service classes 427 - Information about the cache server 429 Note that [6] reports on the results of a field test in which it was 430 attempted to reduce overall traffic by using the above concept to 431 confine traffic exchange destinations to within the same ISP or the 432 same city. It reports that, in an evaluation with a Verizon network, 433 traffic to locations outside an ISP was reduced by 30 to 50% and that 434 the ratio of inter-city traffic to Verizon's total traffic was more 435 or less halved. 437 ISP 438 +------------------------+ Internet 439 | +----------------+ | +------------+ 440 | | iTracker | | | appTracker | 441 | | *Info |--------> +------------+ 442 | | *Policy | | ^ 443 | | *capability | | | 444 | +----------------+ | | 445 | | | 446 | +----------------+ | | 447 | | Peer |----------------+ 448 | +----------------+ | 449 +------------------------+ 451 Figure 2 453 Comparing ALTO with Hint Server technology, the following three 454 differences are observed: 456 o Target of optimization: 458 ALTO technology focuses on optimization within an ISP, while Hint 459 Server technology focuses on optimization in backbone traffic. 461 o Target applications: 463 ALTO technology focuses on supporting BitTorrent, while Hint 464 Server technology does not specify any P2P applications. 466 o Strength of cooperation between P2P providers and ISPs: 468 ALTO technology requires close cooperation between ISPs and P2P 469 providers, while Hint Server technology does not require. 471 5. High-Level Trial Results 473 5.1. Peer Selection with P2P 475 Table 2 shows the result of the analysis of communication in a node 476 of an ISP installed in Tokyo, as an example of measurement results. 478 +-----------------------------------------+------------+------------+ 479 | Conditions | Experiment | Experiment | 480 | | 1 | 2 | 481 +-----------------------------------------+------------+------------+ 482 | *Peers selected within the same ISP | 22% | 29% | 483 | *Peers selected within the same | 19% | 23% | 484 | district | | | 485 | *Peers selected within the same | 5% | 7% | 486 | district and the same ISP | | | 487 +-----------------------------------------+------------+------------+ 489 Table 2: Percentage of communication within the same ISP 491 The table shows that the probability of communication with peers in 492 the same ISP is proportional to the number of population and the 493 share of the ISP in each district. The data show that peers were 494 selected at random. Note that the vendor of a P2P application used 495 in this experiment explained that the mechanism of selection a peer 496 using network information can be implemented. However, peer 497 selection is normally based on past information because users often 498 cannot actually perceive the effect of using network information. 500 5.2. Peer Selection with the Hint Server 502 Since the main objective of this experiment was to verify the 503 operations of the Hint Server and P2P applications, the degree to 504 which traffic in the network was actually reduced was not evaluated. 505 However, the distances between a dummy node and a peer were obtained 506 from data on the dummy nodes. An examination of the distances 507 between a dummy node and a peer revealed that mean value of distance 508 after the Hint Server was introduced was reduced by 10% and that 95% 509 value of that was reduced by 5%. 511 6. Next steps 513 This document has reported on activities aimed at achieving 514 cooperative control between the P2P/overlay network and the network 515 infrastructure. Specifically, it has described issues to be 516 addressed and the activities of the P2P Network Experiment Council in 517 Japan, which was established to address these issues. It has also 518 introduced the Council's activities, from 2007 to 2008, focusing on 519 the use of a Hint Server, which is a feature of the traffic 520 engineering mechanism proposed by the Council. 522 The P2P Network Experiment Council has been renamed the Advanced 523 Network Use Promotion Council. The new Council aims to create new 524 network services suitable for the broadband environment and to 525 promote the widespread use of such services in rural areas. It has 526 expanded its scope of work to include all cache technologies, 527 including P2P technology. It will promote more advanced use of the 528 network by encouraging an exchange of views among a broad spectrum of 529 parties on how to use the network effectively, and by supporting a 530 variety of feasibility tests. 532 The Council aims to continue the analysis of the experiment results 533 obtained, and further study by involving a wider spectrum of P2P 534 providers, network providers and delivery service providers. 536 7. Feedback to ALTO WG 538 This section describes what the authors learned with this experiment 539 would be useful for the ALTO WG. 541 7.1. Harmonizing a Hint Server with ALTO 543 As described before, a Hint Server control mechanism focuses on 544 control between ISPs, while ALTO does control within an ISP. 545 Generally speaking, control mechanism that a peer chooses a replica 546 from its neighbors shows higher performance when probability of a 547 peer having a content is higher. This means ISP cooperation 548 mechanism that enlarges area in choosing peers will have much impact 549 on P2P performance. The authors consider combination of these two 550 mechanisms produce better P2P performance. The authors propose 551 hierarchical structure to harmonize a Hint Server with ALTO. From 552 viewpoint of cooperation between ISPs, fine information is not 553 necessarily required and it is difficult to exchange fine information 554 between ISPs. Considering this situation, the authors use only 555 coarse information to control backbone traffic in the experiments 556 this year, though demand of controlling traffic within an ISP using 557 fine information will arise in the near future. The authors consider 558 that introducing hierarchical structure into ALTO is necessary to 559 cope with both situations. Actually, the authors plan to try a 560 hierarchical control mechanism in the next steps, which include the 561 following two steps. 563 o In the first step, coarse information about whole the network is 564 used to select ISPs. 566 o Next, fine information within the ISP is used to select a peer. 568 7.2. Measurement mechanism 570 In experiments, there were two difficulties as follows: 572 o Evaluating effect of introducing a Hint Server was difficult, 573 since P2P applications had their own measurement mechanisms. 575 o How to treat priority orders of peers suggested by a Hint Server 576 could not be predetermined for P2P applications. 578 From these experiences, the authors consider that clarifying 579 requirements about measurement mechanisms for P2P applications are 580 necessary also in Alto. 582 8. Security Considerations 584 There are no security considerations in this document. 586 9. IANA Considerations 588 No need to describe any request regarding number assignment. 590 10. Acknowledgments 592 These experiments were performed under cooperation among P2P Network 593 Experiment Council members, and DREAMBOAT co.,ltd., Bitmedia Inc., 594 Utagoe. Inc. and Toyama IX have especially supported analyses of the 595 experimernts. The authors appreciate Tohru Asami, Hiroshi Esaki and 596 Tatsuya Yamshita for their constructive comments. 598 11. Informative References 600 [1] Hiroshi Esaki, "The State of Traffic and the Effects of P2P", 601 Special Symposium on Broadband, September 2008 (in Japanese). 603 [2] Yoichi Yamazaki, "ISPs have Begun to Explore Tomorrow due to the 604 Expansion of Traffic", Nikkei Communications, December 2007 (in 605 Japanese). 607 [3] TVBank, "Live Delivery using `BB Broadcast'Achieving 96% Saving 608 in Traffic!", http:.wwww.tv-bank.com/jp/20081031.html, 2008 (in 609 Japanese). 611 [4] Ministry of Internal Affairs and Communications, "Disclosure of 612 the Report `Working Group on P2P Networks'", 613 http://www.soumu.go.jp/menu_news/s-news/2007/070629_11.html, 614 2007 (in Japanese). 616 [5] The Foundation for MultiMedia Communications, "The P2P Network 617 Experiment Council", http://www.fmmc.or.jp/P2P/about.htm, 2007 618 (in Japanese). 620 [6] Open P4P, "P4P Field Tests: Yale-Pando-Verizon", 621 http://www.openp4p.net/front/fieldests, 2009. 623 Authors' Addresses 625 Satoshi Kamei 626 NTT Service Integration Laboratories 627 3-9-11, Midori-cho 628 Musashino-shi, Tokyo 180-8585 629 JP 631 Phone: +81-422-59-6942 632 Email: kamei.satshi@lab.ntt.co.jp 634 Tsuyoshi Momose 635 Cisco Systems G.K. 636 2-1-1 Nishi-Shinjuku 637 Shinjuku-ku, Tokyo 163-0409 638 JP 640 Phone: +81-3-5324-4154 641 Email: tmomose@cisco.com 642 Takeshi Inoue 643 NTT Communications 644 3-4-1, Shibaura 645 Minato-ku, Tokyo 108-8118 646 JP 648 Phone: +81-3-6733-7177 649 Email: inoue@jp.ntt.net 651 Tomhiro Nishitani 652 NTT Communications 653 1-2-20, Kaigan 654 Minato-ku, Tokyo 105-8535 655 JP 657 Phone: +81-50-3812-4742 658 Email: tomoniro.nishitani@ntt.com