idnits 2.17.1 draft-kamei-p2p-experiments-japan-04.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 (November 20, 2010) is 4877 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '6' is defined on line 631, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 636, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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: May 24, 2011 Cisco Systems 6 T. Inoue 7 T. Nishitani 8 NTT Communications 9 November 20, 2010 11 ALTO-Like Activities and Experiments in P2P Network Experiment Council 12 draft-kamei-p2p-experiments-japan-04 14 Abstract 16 This document provides some suggestions about ALTO architecture 17 through experiments made by P2P Network Experiment Council in Japan. 18 This document also introduces experiments made by the Council in 19 Japan to harmonize P2P technology with the infrastructure. 20 Specifically, this document describes Hint Server technology, which 21 is similar to ALTO technology. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on May 24, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Background in Japan . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. P2P traffic . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Impact on network infrastructure . . . . . . . . . . . . . 4 67 3. Activity in P2P Network Experiment Council . . . . . . . . . . 5 68 3.1. Dummy Node . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.2. Hint Server ('08) . . . . . . . . . . . . . . . . . . . . 5 70 3.3. Difference between P4P and Hint Server technology . . . . 9 71 3.4. Difference between ALTO and Hint Server technology . . . . 11 72 4. High-Level Trial Results . . . . . . . . . . . . . . . . . . . 11 73 4.1. Peer Selection with P2P . . . . . . . . . . . . . . . . . 11 74 4.2. Peer Selection with the Hint Server . . . . . . . . . . . 12 75 5. Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 6. Feedback to ALTO WG . . . . . . . . . . . . . . . . . . . . . 13 77 6.1. Harmonizing a Hint Server with ALTO . . . . . . . . . . . 13 78 6.2. Measurement mechanism . . . . . . . . . . . . . . . . . . 13 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 82 10. Informative References . . . . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 An overlay network, which is used by P2P and other applications, 88 offers the advantage of allowing flexible provision of services while 89 hiding the lower layer network. The downside is that inefficient 90 routes are often taken in the lower IP network, thereby increasing 91 the network load. Several proposals have been made to build an 92 overlay network that takes account of the information about the lower 93 layer network. Since the management of the Internet is highly 94 distributed, it is difficult to implement such proposals and thus 95 optimize a network without the cooperation of network providers. 97 Recently, the controversy between the overlay network and the network 98 providers have been rekindled. Under these circumstances, some 99 researchers have studied overlay network control technology that 100 takes account of the network topology information obtained from 101 network providers. 103 One of activities concerning this issue has been made by the P2P 104 Network Experiment Council in Japan. This document reports on the 105 issues addressed and experiments being made by the P2P Network 106 Experiment Council in Japan, focusing on the experiments made from 107 2007 to 2008. 109 2. Background in Japan 111 2.1. P2P traffic 113 In Japan, the major of P2P applications used today is Winny [1]. P2P 114 applications are the sources of a considerable volume of traffic. 115 Recent study [2] showed more than 60% of Internet traffic in Japan is 116 generated by P2P applications. 118 Although traffic from P2P applications increased much more rapidly 119 than traffic from client-server-type web applications, it has leveled 120 off lately as a result of legal restrictions advocated by copyright 121 management organizations and traffic control implemented by ISPs. 122 According to [3], video delivery sites using Flash has again 123 increased volume of web traffic per user, making P2P traffic 124 relatively less conspicuous than before. 126 Consequently, some believe that P2P traffic is no longer a threat to 127 the infrastructure. P2P applications, however, rapidly became widely 128 used to get around the limit of the servers' capacity, which was 129 caused by the increase in demand for delivery of music files. As of 130 2007, it was likely that the traffic of client-server video delivery 131 would shift to P2P delivery. 133 In fact, some P2P content delivery systems solve copyright issues, 134 for example, Sharecast, Ocean-Grid, TVBand, and so on. The 135 transmission of President Obama's Inaugural Address, which is the 136 largest-scale transmission of content in recent history, was mostly 137 of the client-server type. However, the delivery by CNN used a P2P 138 plug-in made by Octoshape. 140 2.2. Impact on network infrastructure 142 One of advantage of using P2P technology for content delivery is that 143 peers exchange content directly among themselves. This reduces the 144 load on servers. Also, P2P applications can reduce upstream traffic 145 from an original content server. This is significant that the charge 146 for upstream traffic is usually traffic-sensitive for content 147 delivery services, and it is not negligible. 149 Actually, the volume of traffic sent by the content server in 150 TVBank's P2P content delivery was reduced by a maximum of 96% 151 compared with the volume of traffic received by users [4]. This 152 indicates the great cost-saving of P2P technology from the 153 perspectives of the load on server hardware and the traffic relaying 154 cost of data centers. However, the story is quite different for 155 network providers. From viewpoint of network providers, the traffic 156 that content servers generate has shifted to the edge network and the 157 amount of traffic has not necessarily been reduced. Another problem 158 for network providers that an extremely inefficient routing may be 159 selected has been raised. It is because overlay network systems are 160 configured without any regard to the structure of the lower layer 161 network or network geometry. 163 In some cases, traffic on the Internet used to be limited by the 164 capacity of servers. For those cases, the improvement in the 165 scalability of servers has made it likely that network resources will 166 be used up before server resources are. Using P2P applications 167 increases the volume of traffic per user remarkably. 169 Faced with increase in the load on network infrastructure, network 170 providers are compelled to take actions to overcome the sudden 171 increase in facilities' cost. Representative actions include placing 172 content in IXs or data centers, introducing bandwidth control, and 173 raising the access fees [2]. 175 In the future, video posting sites, which has been delivered using 176 client-server applications, may adopt P2P system. The increase in 177 traffic arising from such a shift will be a great threat to the 178 network. 180 3. Activity in P2P Network Experiment Council 182 3.1. Dummy Node 184 While the effect of delivery using P2P technology on reducing the 185 traffic and the load on servers is well known, traffic behavior in 186 the Internet is not known. However, it is not realistic to measure 187 the behavior of P2P applications at user terminals connected to the 188 Internet because that would require a large-scale arrangement for 189 measurement, such as using Deep Packet Inspection (DPI) on aggregated 190 lines. To solve this problem, dummy nodes which act like consumers 191 node have been introduced. Dummy nodes have been settled in the 192 Internet and P2P applications have been installed on these nodes. 193 Dummy nodes enable us to measure and analyze communication among 194 peers. 196 Specifically, Linux servers were installed at 40 sites of some ISPs, 197 and a virtual Windows environment was installed on the servers. P2P 198 applications which were target to measure were running on that 199 environment, and packets were captured by a Linux program to obtain 200 information on communication destinations and communication 201 frequencies. The nodes are placed on data centers, however, it 202 wasn't matter because the bandwidth limited the subscribers line 203 isn't mesured in this experiment. 205 3.2. Hint Server ('08) 207 In Japan, bottleneck in IP networks will shift from access networks 208 to backbone networks and equipments, such as bandwidth between ISPs 209 and capacity in IXs, since FTTH has rapidly spread all over Japan. 210 Under this situation. the Council proposed a less restrictive and 211 more flexible cooperation between ISPs than ALTO. The proposed 212 method consists of the following elements: (1) P2P clients, (2) P2P 213 control servers, and (3) a peer selection hint server, and a Hint 214 Server. (1) and (2) are existing systems but whether (2) exists 215 depends on each application. (3) is a server that provides a hint as 216 to the selection of a peer, and plays a role equivalent to that of 217 iTracker in P4P's study. Note that this proposal was based on 218 results of experiments using dummy nodes. The results showed that it 219 was possible to reduce unnecessary traffic that flows across the 220 boundaries of districts or ISPs through providing information about 221 the physical network to P2P applications. 223 When a peer joins the network, it registers its location information 224 (IP address) and supplementary information (line speed, etc.) with 225 the Hint Server. The Hint Server makes a mapping of the new peer 226 (P2P client) based on network topology information obtained from the 227 ISP, generates a routing table in which peers are listed in the order 228 of priority for selection, and returns the table to the peer. 230 If all information can be made public, the above procedure can 231 produce a result which is close to overall optimization. However, 232 some information held by ISPs can often be confidential. Besides, in 233 some cases, the volume of calculation required to process all 234 information can be excessive. To avoid these problems, it is planned 235 to conduct experiments with a limited set of functions, analyze 236 experiment results, and gradually expand the scope of optimization. 238 A control mechanism that makes use of all possible information is 239 difficult not only technically but also because it is difficult to 240 achieve coordination among providers. In consideration of these 241 difficulties, the P2P Network Experiment Council has been limiting 242 the implementation and experiments to the following scope since 2006. 244 Figure 1 shows an outline of the hint server. 246 +---------+ GetLocation +-------------GeoIP DB Server---------+ 247 | | +-----------+ | +----------+ +-----------+ | 248 | |--|IP Address |-->| | GeoIP DB | |Quagga etc | | 249 | | +-----------+ | +----------+ +-----------+ | 250 | | | +-------------+ +----------------+ | 251 | | +-----------+ | | District | | Routing | | 252 | |--|AS Code: |---| | information | |information(DGP)| | 253 | | |Regional | | | | | | | 254 |P2P Peers| |Information| | | Range of | |AS Code(origin) | | 255 | or | +-----------+ | | IP address | | | | 256 | Contro| | | +-------------+ +----------------+ | 257 | Server | +-------------------------------------+ 258 | | | ^ 259 | | PeerSelection v | 260 | | +-----------+ +--------------------------------------+ 261 | |--|IP Address |-->| +--Prioryty Node Selection System--+ | 262 | | | List | | | | | 263 | | +-----------+ | | Peer candidate ranking | | 264 | | +-----------+ | | | | 265 | |--| Ranking |-->| +----------------------------------+ | 266 | | +-----------+ +--------------------------------------+ 267 +---------+ 269 Figure 1 271 The network information used by the Hint Server is not information 272 solicited from individual ISPs but the AS number and district 273 information, which are more or less already public. Routing tables 274 are not generated. Instead, peers within the same ISP or the same 275 district are selected with higher priority in order to confine 276 traffic to within the same ISP or the same district. 278 When the Hint Server receives an IP address, it returns its attribute 279 information, to achieve the above. A peer can select a peer based on 280 the returned information. This operation is called GetLocation. 281 However, in preparation for the time when it becomes necessary to 282 hide topology information, an interface is provided through which a 283 priority order is returned in response to an input of a list of 284 candidate peers. This operation is called PeerSelection. 286 Although the priority node is selected based on the criterion that it 287 is within the same ISP or the same district, this type of selection 288 is not very effective if the number of participating peers is small. 289 Table 1 shows ratio of peers within the same AS or the same 290 prefecture calculated from the distribution of ASs and prefectures in 291 the IP address space from one-day data on a Winny network. 293 +--------------------+--------+ 294 | Conditions | ratio | 295 +--------------------+--------+ 296 | AS matches | 6.70% | 297 | Prefecture matches | 12.76% | 298 | Both match | 2.09% | 299 | Neither match | 78.45% | 300 +--------------------+--------+ 302 Table 1: AS and prefecture distributions 304 Since, in addition to the above, the presence/absence of content 305 affects the result, the control of selecting a peer within the same 306 district may be inadequate. Therefore, it is necessary to introduce 307 the weight of a continuous quantity that reflects the physical 308 distance or the AS path length as an indicator of the proximity of 309 the areas involved. 311 In consideration of the above, the following two measures are used 312 for the evaluation of proximity between peers in a Hint Server. 314 o AS path length (distance between ISPs) 316 Distances between peers are weighted using the degree of paths' 317 matching from an origin AS to ASs that target peers belong to. 318 The degree of paths' matching means ratio of common paths from an 319 origin AS (for example, 4/6 between A-B-C, and A-B-D, 6/8 between 320 A-B-C-D and A-B-C-E). In this year, the OCN is used as an origin 321 AS. Distance is calculated as int((1.0- degree of matching of AS 322 paths)*15). Distance is 15 if either of AS path is indefinite, 323 and is 0 if there is a perfect match. 325 o Physical distance 327 Distances between peers are measured using physical distance of 328 prefectural capitals that target peers belong to. The distance 329 between prefectural capitals is used to calculate physical 330 distance. Distances between prefectural capitals are sorted into 331 ascending order, and then into bands, with weights 1 to 15 332 assigned to them so that there are a more or less equal number of 333 "capital pairs" in each band. If either of their location is 334 indefinite, distance is equal to 15 and, if they are in the same 335 prefecture, distance is equal to 0. 337 Evaluation of distances between peers showed that the distribution 338 of distances was almost uniform when distances between peers are 339 normalized. This result suggests that using normalized distances 340 expands the area where the control by a Hint Server is effective. 342 An example of the request and the response 344 o Request 346 POST /PeerSelection HTTP/1.1 347 Host: ServerName 348 User-Agent: ClientName 349 Content-Type: text/plain; charset=utf-8 351 v=Version number 352 [application=Application identifier] 353 ip=IP address of physical interface 354 port=Port number of physical interface 355 [nat={no|upnp|unknown}] 356 [nat_ip=Global IP address using UPnP] 357 [nat_port= Global port number using UPnP] 358 [trans_id=transcation ID] 359 [pt=Flag of port type] 360 [ub=upload bandwidth] 361 [db=download bandwidth] 363 o Response 365 HTTP/1.1 200 OK 366 Date: Timestamp 367 Content-Type: text/plain; charset=utf-8 368 Cache-control: max-age=max age 369 Connection: close 371 v=Version number 372 ttl=ttl 373 server=hint server name 374 ... 375 trans_id=transaction ID 376 pt=Flag of port type 377 client_ip=Peer IP address observed from server 378 client_port=Peer port number observed from server 379 numpeers=number of respond peer 380 n=[src address] dst address / cost / option 382 3.3. Difference between P4P and Hint Server technology 384 To explain difference between P4P and Hint Server technology, the 385 architecture proposed by P4P is described. P4P aims to control 386 traffic in such a way that traffic is confined within the same 387 district or AS. As shown in Figure 2, iTracker provides an interface 388 for P2P content delivery using appTracker and peers in BitTorrent. 389 This arrangement provides a framework for efficient control based on 390 network information. 392 In this framework, it is proposed that ISPs and applications share 393 the following types of information through iTracker: 395 o Info: information about peers within an ISP 397 - ASID AS number 399 - Group number of PID node (peer) 401 - LOC: virtual and geographical coordinates 403 o Policy: information about policy on usage specified by an ISP 405 - Ratio between outgoing traffic and incoming traffic that flows 406 between domains 407 - Desirable daily traffic variation pattern on a link 409 - Specifications about relations between peer groups (PID) 411 o Capability: information about the capability of an ISP 413 - Information about usable service classes 415 - Information about the cache server 417 Note that [5] reports on the results of a field test in which it was 418 attempted to reduce overall traffic by using the above concept to 419 confine traffic exchange destinations to within the same ISP or the 420 same city. It reports that, in an evaluation with a Verizon network, 421 traffic to locations outside an ISP was reduced by 30 to 50% and that 422 the ratio of inter-city traffic to Verizon's total traffic was more 423 or less halved. 425 ISP 426 +------------------------+ Internet 427 | +----------------+ | +------------+ 428 | | iTracker | | | appTracker | 429 | | *Info |--------> +------------+ 430 | | *Policy | | ^ 431 | | *capability | | | 432 | +----------------+ | | 433 | | | 434 | +----------------+ | | 435 | | Peer |----------------+ 436 | +----------------+ | 437 +------------------------+ 439 Figure 2 441 Comparing P4P with Hint Server technology, the following three 442 differences are observed: 444 o Target of optimization: 446 P4P technology focuses on optimization within an ISP, while Hint 447 Server technology focuses on optimization in backbone traffic. 449 o Target applications: 451 P4P technology focuses on supporting BitTorrent, while Hint Server 452 technology does not specify any P2P applications. 454 o Strength of cooperation between P2P providers and ISPs: 456 P4P technology requires close cooperation between ISPs and P2P 457 providers, while Hint Server technology does not require. 459 3.4. Difference between ALTO and Hint Server technology 461 ALTO technology is more general approach than P4P technology. And 462 Hint Server technology has more similar focus of this technology. 464 Hint Server offers similar information of ALTO service and can easily 465 supports following ALTO Services. 467 o Map Service 469 The cost type is computed by physical distance and AS path length, 470 and the mode is numerical. 472 PID information, it is same as AS and physical location, does not 473 offered to client. 475 o Map Filtering Service 477 o Endpoint Cost Service 479 Hint Server only offers map information associated with requested 480 IP addresses. 482 ALTO framework has more generality but the following two points are 483 not sufficiently improved or some operational solution should be 484 offered. 486 4. High-Level Trial Results 488 4.1. Peer Selection with P2P 490 Table 2 shows the result of the analysis of communication in a node 491 of an ISP installed in Tokyo, as an example of measurement results. 493 +-----------------------------------------+------------+------------+ 494 | Conditions | Experiment | Experiment | 495 | | 1 | 2 | 496 +-----------------------------------------+------------+------------+ 497 | *Peers selected within the same ISP | 22% | 29% | 498 | *Peers selected within the same | 19% | 23% | 499 | district | | | 500 | *Peers selected within the same | 5% | 7% | 501 | district and the same ISP | | | 502 +-----------------------------------------+------------+------------+ 504 Table 2: Percentage of communication within the same ISP 506 The table shows that the probability of communication with peers in 507 the same ISP is proportional to the number of population and the 508 share of the ISP in each district. The data show that peers were 509 selected at random. Note that the vendor of a P2P application used 510 in this experiment explained that the mechanism of selection a peer 511 using network information can be implemented. However, peer 512 selection is normally based on past information because users often 513 cannot actually perceive the effect of using network information. 515 4.2. Peer Selection with the Hint Server 517 Since the main objective of this experiment was to verify the 518 operations of the Hint Server and P2P applications, the degree to 519 which traffic in the network was actually reduced was not evaluated. 520 However, the distances between a dummy node and a peer were obtained 521 from data on the dummy nodes. An examination of the distances 522 between a dummy node and a peer revealed that mean value of distance 523 after the Hint Server was introduced was reduced by 10% and that 95% 524 value of that was reduced by 5%. 526 5. Next steps 528 This document has reported on activities aimed at achieving 529 cooperative control between the P2P/overlay network and the network 530 infrastructure. Specifically, it has described issues to be 531 addressed and the activities of the P2P Network Experiment Council in 532 Japan, which was established to address these issues. It has also 533 introduced the Council's activities, from 2007 to 2008, focusing on 534 the use of a Hint Server, which is a feature of the traffic 535 engineering mechanism proposed by the Council. 537 The P2P Network Experiment Council has been renamed the Advanced 538 Network Use Promotion Council. The new Council aims to create new 539 network services suitable for the broadband environment and to 540 promote the widespread use of such services in rural areas. It has 541 expanded its scope of work to include all cache technologies, 542 including P2P technology. It will promote more advanced use of the 543 network by encouraging an exchange of views among a broad spectrum of 544 parties on how to use the network effectively, and by supporting a 545 variety of feasibility tests. 547 The Council aims to continue the analysis of the experiment results 548 obtained, and further study by involving a wider spectrum of P2P 549 providers, network providers and delivery service providers. 551 6. Feedback to ALTO WG 553 This section describes what the authors learned with this experiment 554 would be useful for the ALTO WG. 556 6.1. Harmonizing a Hint Server with ALTO 558 As described before, a Hint Server control mechanism focuses on 559 control between ISPs, while ALTO does control within an ISP. 560 Generally speaking, control mechanism that a peer chooses a replica 561 from its neighbors shows higher performance when probability of a 562 peer having a content is higher. This means ISP cooperation 563 mechanism that enlarges area in choosing peers will have much impact 564 on P2P performance. The authors consider combination of these two 565 mechanisms produce better P2P performance. The authors propose 566 hierarchical structure to harmonize a Hint Server with ALTO. From 567 viewpoint of cooperation between ISPs, fine information is not 568 necessarily required and it is difficult to exchange fine information 569 between ISPs. Considering this situation, the authors use only 570 coarse information to control backbone traffic in the experiments 571 this year, though demand of controlling traffic within an ISP using 572 fine information will arise in the near future. The authors consider 573 that introducing hierarchical structure into ALTO is necessary to 574 cope with both situations. Actually, the authors plan to try a 575 hierarchical control mechanism in the next steps, which include the 576 following two steps. 578 o In the first step, coarse information about whole the network is 579 used to select ISPs. 581 o Next, fine information within the ISP is used to select a peer. 583 6.2. Measurement mechanism 585 In experiments, there were two difficulties as follows: 587 o Evaluating effect of introducing a Hint Server was difficult, 588 since P2P applications had their own measurement mechanisms. 590 o How to treat priority orders of peers suggested by a Hint Server 591 could not be predetermined for P2P applications. 593 From these experiences, the authors consider that clarifying 594 requirements about measurement mechanisms for P2P applications are 595 necessary also in Alto. 597 7. Security Considerations 599 There are no security considerations in this document. 601 8. IANA Considerations 603 No need to describe any request regarding number assignment. 605 9. Acknowledgments 607 These experiments were performed under cooperation among P2P Network 608 Experiment Council members, and DREAMBOAT co.,ltd., Bitmedia Inc., 609 Utagoe. Inc. and Toyama IX have especially supported analyses of the 610 experimernts. The authors appreciate Tohru Asami, Hiroshi Esaki and 611 Tatsuya Yamshita for their constructive comments. 613 10. Informative References 615 [1] "Winny on Wikipedia", . 617 [2] Hiroshi Esaki, "The State of Traffic and the Effects of P2P", 618 Special Symposium on Broadband, September 2008 (in Japanese). 620 [3] Yoichi Yamazaki, "ISPs have Begun to Explore Tomorrow due to the 621 Expansion of Traffic", Nikkei Communications, December 2007 (in 622 Japanese). 624 [4] TVBank, "Live Delivery using `BB Broadcast'Achieving 96% Saving 625 in Traffic!", http:.wwww.tv-bank.com/jp/20081031.html, 2008 (in 626 Japanese). 628 [5] Open P4P, "P4P Field Tests: Yale-Pando-Verizon", 629 http://www.openp4p.net/front/fieldests, 2009. 631 [6] Ministry of Internal Affairs and Communications, "Disclosure of 632 the Report `Working Group on P2P Networks'", 633 http://www.soumu.go.jp/menu_news/s-news/2007/070629_11.html, 634 2007 (in Japanese). 636 [7] The Foundation for MultiMedia Communications, "The P2P Network 637 Experiment Council", http://www.fmmc.or.jp/P2P/about.htm, 2007 638 (in Japanese). 640 Authors' Addresses 642 Satoshi Kamei 643 NTT Service Integration Laboratories 644 3-9-11, Midori-cho 645 Musashino-shi, Tokyo 180-8585 646 JP 648 Phone: +81-422-59-6942 649 Email: kamei.satoshi@lab.ntt.co.jp 651 Tsuyoshi Momose 652 Cisco Systems G.K. 653 2-1-1 Nishi-Shinjuku 654 Shinjuku-ku, Tokyo 163-0409 655 JP 657 Phone: +81-3-5324-4154 658 Email: tmomose@cisco.com 660 Takeshi Inoue 661 NTT Communications 662 3-4-1, Shibaura 663 Minato-ku, Tokyo 108-8118 664 JP 666 Phone: +81-3-6733-7177 667 Email: inoue@jp.ntt.net 669 Tomohiro Nishitani 670 NTT Communications 671 1-2-20, Shibaura 672 Minato-ku, Tokyo 108-8118 673 JP 675 Phone: +81-50-3812-4742 676 Email: tomohiro.nishitani@ntt.com