idnits 2.17.1 draft-kamei-p2p-experiments-japan-03.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 (May 20, 2010) is 5089 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PRG S. Kamei 3 Internet-Draft NTT Corporation 4 Intended status: Informational T. Momose 5 Expires: November 21, 2010 Cisco Systems 6 T. Inoue 7 T. Nishitani 8 NTT Communications 9 May 20, 2010 11 ALTO-Like Activities and Experiments in P2P Network Experiment Council 12 draft-kamei-p2p-experiments-japan-03 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 November 21, 2010. 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. The object of P2P Network Experiment Council . . . . . . . . . 5 68 4. Activity in P2P Network Experiment Council . . . . . . . . . . 6 69 4.1. Dummy Node . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. Hint Server ('08) . . . . . . . . . . . . . . . . . . . . 6 71 4.3. Difference between P4P and Hint Server technology . . . . 10 72 4.4. Difference between ALTO and Hint Server technology . . . . 12 73 5. High-Level Trial Results . . . . . . . . . . . . . . . . . . . 12 74 5.1. Peer Selection with P2P . . . . . . . . . . . . . . . . . 13 75 5.2. Peer Selection with the Hint Server . . . . . . . . . . . 13 76 6. Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 7. Feedback to ALTO WG . . . . . . . . . . . . . . . . . . . . . 14 78 7.1. Harmonizing a Hint Server with ALTO . . . . . . . . . . . 14 79 7.2. Measurement mechanism . . . . . . . . . . . . . . . . . . 15 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 83 11. Informative References . . . . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 An overlay network, which is used by P2P and other applications, 89 offers the advantage of allowing flexible provision of services while 90 hiding the lower layer network. The downside is that inefficient 91 routes are often taken in the lower IP network, thereby increasing 92 the network load. Several proposals have been made to build an 93 overlay network that takes account of the information about the lower 94 layer network. Since the management of the Internet is highly 95 distributed, it is difficult to implement such proposals and thus 96 optimize a network without the cooperation of network providers. 98 Recently, the controversy between the overlay network and the network 99 providers have been rekindled. Under these circumstances, some 100 researchers have studied overlay network control technology that 101 takes account of the network topology information obtained from 102 network providers. 104 One of activities concerning this issue has been made by the P2P 105 Network Experiment Council in Japan. This document reports on the 106 issues addressed and experiments being made by the P2P Network 107 Experiment Council in Japan, focusing on the experiments made from 108 2007 to 2008. 110 2. Background in Japan 112 2.1. P2P traffic 114 In Japan, the major of P2P applications used today is Winny. P2P 115 applications are the sources of a considerable volume of traffic. 116 Recent study [1] showed more than 60% of Internet traffic in Japan is 117 generated by P2P applications. 119 Although traffic from P2P applications increased much more rapidly 120 than traffic from client-server-type web applications, it has leveled 121 off lately as a result of legal restrictions advocated by copyright 122 management organizations and traffic control implemented by ISPs. 123 According to [2], video delivery sites using Flash has again 124 increased volume of web traffic per user, making P2P traffic 125 relatively less conspicuous than before. 127 Consequently, some believe that P2P traffic is no longer a threat to 128 the infrastructure. P2P applications, however, rapidly became widely 129 used to get around the limit of the servers' capacity, which was 130 caused by the increase in demand for delivery of music files. It is 131 likely that the traffic of client-server video delivery will shift to 132 P2P delivery. 134 In fact, some P2P content delivery systems solve copyright issues, 135 for example, Sharecast, Ocean-Grid, TVBand, and so on. The 136 transmission of President Obama's Inaugural Address, which is the 137 largest-scale transmission of content in recent history, was mostly 138 of the client-server type. However, the delivery by CNN used a P2P 139 plug-in made by Octoshape. Traffic data observed by Illinois 140 University revealed unique traffic patterns that the upstream traffic 141 exceeded the downstream traffic. 143 2.2. Impact on network infrastructure 145 One of advantage of using P2P technology for content delivery is that 146 peers exchange content directly among themselves. This reduces the 147 physical load on servers . Also, P2P applications can reduce 148 upstream traffic from an original content server. This is 149 significant that the charge for upstream traffic is usually traffic- 150 sensitive for content delivery services, and it is not negligible. 152 Actually, the volume of traffic sent by the content server in 153 TVBank's P2P content delivery was reduced by a maximum of 96% 154 compared with the volume of traffic received by users [3]. This 155 indicates the great cost-saving of P2P technology from the 156 perspectives of the load on server hardware and the traffic relaying 157 cost of data centers. However, the story is quite different for 158 network providers. From viewpoint of network providers, the traffic 159 that content servers generate has shifted to the edge network and the 160 amount of traffic has not necessarily been reduced. Another problem 161 for network providers that an extremely inefficient routing may be 162 selected has been raised. It is because overlay network systems are 163 configured without any regard to the structure of the lower layer 164 network or network geometry. 166 Traffic on the Internet used to be limited by the capacity of 167 servers. Today the improvement in the scalability of servers has 168 made it likely that network resources will be used up before server 169 resources are. Using P2P applications increases the volume of 170 traffic per user remarkably. 172 Faced with increase in the load on network infrastructure, network 173 providers are compelled to take actions to overcome the sudden 174 increase in facilities' cost. Representative actions include placing 175 content in IXs or data centers, introducing bandwidth control, and 176 raising the access fees [2]. 178 In the future, video posting sites, which has been delivered using 179 client-server applications, may adopt P2P system. The increase in 180 traffic arising from such a shift will be a great threat to the 181 network. 183 3. The object of P2P Network Experiment Council 185 The Japanese Ministry of Internal Affairs and Communications, which 186 has jurisdiction over information and communication systems in Japan, 187 held meetings of an advisory panel on network neutrality from 2006 to 188 2007 in order to study issues related to next generation networks, 189 such as how to ensure fairness in the use of networks and how to 190 define fairness in cost burden. The panel took an interest in P2P 191 technology as a solution to the impending traffic saturation in the 192 backbone network resulting from the rapid expansion of broadband 193 access in Japan, and formed a "Working Group on the P2P Network", 194 which carried out an intensive study of P2P networks. 196 The Working Group reported that it is necessary to undertake the 197 following four activities, which are intended to encourage the 198 government to adopt relevant policies [4]: 200 o Formulate guidelines to be self-imposed by the industry on P2P 201 file delivery applications, 203 o Promote feasibility tests of P2P networks, 205 o Study the current state of traffic control and promote the sharing 206 of information, 208 o Hold working group meetings on traffic control. 210 The first two proposals led to the establishment of the P2P Network 211 Experiment Council supported by the Japanese Ministry of Internal 212 Affairs and Communications [5]. The Council, with membership from 213 P2P delivery providers, content holders, and network providers, began 214 a variety of delivery experiments, which were expected to strengthen 215 cooperative control between different layers. In contrast to P4P, 216 which takes a relatively top-down approach of adopting architecture 217 based on a proposal from a university, the Council is characterized 218 by its bottom-up approach. The aim of establishing the Council has 219 been described as follows. 221 The rapid growth of broadband access enables content delivery 222 system to deliver high-quality and high-volume videos securely and 223 efficiently. Although P2P technology is an effective technology 224 for this requirement, it still has some issues to be coped with. 225 Therefore, the "P2P Network Experiment Council" was established 226 with the support of the Japanese Ministry of Internal Affairs and 227 Communications with its secretariat set up within the Foundation 228 for MultiMedia Communications (FMMC) in order to formulate 229 guidelines for providers and conduct feasibility tests so that 230 users can receive video delivery services safely. 232 The activities of the P2P Network Experiment Council can be 233 classified into two categories. The first is activities to formulate 234 guidelines for the promotion of the commercial use of P2P technology. 235 These will enable users to use P2P technology safely, and providers 236 to have clear rules they must observe. The other is feasibility 237 tests of P2P technology. The next section mainly reports on 238 experiments conducted from 2007 to 2008. 240 4. Activity in P2P Network Experiment Council 242 4.1. Dummy Node 244 While the effect of delivery using P2P technology on reducing the 245 traffic and the load on servers is well known, traffic behavior in 246 the Internet is not known. However, it is not realistic to measure 247 the behavior of P2P applications at user terminals connected to the 248 Internet because that would require a large-scale arrangement for 249 measurement, such as using Deep Packet Inspection (DPI) on aggregated 250 lines. To solve this problem, dummy nodes have been introduced. 251 Dummy nodes have been settled in the Internet and P2P applications 252 have been installed on these nodes. Dummy nodes enable us to measure 253 and analyze communication among peers. 255 Specifically, Linux servers were installed at 40 sites of some ISPs, 256 and a virtual Windows environment was installed on the servers. P2P 257 applications which were target to measure were running on that 258 environment, and packets were captured by a Linux program to obtain 259 information on communication destinations and communication 260 frequencies. 262 4.2. Hint Server ('08) 264 In Japan, bottleneck in IP networks will shift from access networks 265 to backbone networks and equipments, such as bandwidth between ISPs 266 and capacity in IXs, since FTTH has rapidly spread all over Japan. 267 Under this situation. the Council proposed a less restrictive and 268 more flexible cooperation between ISPs than ALTO. The proposed 269 method consists of the following elements: (1) P2P clients, (2) P2P 270 control servers, and (3) a peer selection hint server, and a Hint 271 Server. (1) and (2) are existing systems but whether (2) exists 272 depends on each application. (3) is a server that provides a hint as 273 to the selection of a peer, and plays a role equivalent to that of 274 iTracker in P4P's study. Note that this proposal was based on 275 results of experiments using dummy nodes. The results showed that it 276 was possible to reduce unnecessary traffic that flows across the 277 boundaries of districts or ISPs through providing information about 278 the physical network to P2P applications. 280 When a peer joins the network, it registers its location information 281 (IP address) and supplementary information (line speed, etc.) with 282 the Hint Server. The Hint Server makes a mapping of the new peer 283 (P2P client) based on network topology information obtained from the 284 ISP, generates a routing table in which peers are listed in the order 285 of priority for selection, and returns the table to the peer. 287 If all information can be made public, the above procedure can 288 produce a result which is close to overall optimization. However, 289 some information held by ISPs can often be confidential. Besides, in 290 some cases, the volume of calculation required to process all 291 information can be excessive. To avoid these problems, it is planned 292 to conduct experiments with a limited set of functions, analyze 293 experiment results, and gradually expand the scope of optimization. 295 A control mechanism that makes use of all possible information is 296 difficult not only technically but also because it is difficult to 297 achieve coordination among providers. In consideration of these 298 difficulties, the P2P Network Experiment Council has been limiting 299 the implementation and experiments to the following scope since 2006. 301 Figure 1 shows an outline of the hint server. 303 +---------+ GetLocation +-------------GeoIP DB Server---------+ 304 | | +-----------+ | +----------+ +-----------+ | 305 | |--|IP Address |-->| | GeoIP DB | |Quagga etc | | 306 | | +-----------+ | +----------+ +-----------+ | 307 | | | +-------------+ +----------------+ | 308 | | +-----------+ | | District | | Routing | | 309 | |--|AS Code: |---| | information | |information(DGP)| | 310 | | |Regional | | | | | | | 311 |P2P Peers| |Information| | | Range of | |AS Code(origin) | | 312 | or | +-----------+ | | IP address | | | | 313 | Contro| | | +-------------+ +----------------+ | 314 | Server | +-------------------------------------+ 315 | | | ^ 316 | | PeerSelection v | 317 | | +-----------+ +--------------------------------------+ 318 | |--|IP Address |-->| +--Prioryty Node Selection System--+ | 319 | | | List | | | | | 320 | | +-----------+ | | Peer candidate ranking | | 321 | | +-----------+ | | | | 322 | |--| Ranking |-->| +----------------------------------+ | 323 | | +-----------+ +--------------------------------------+ 324 +---------+ 326 Figure 1 328 The network information used by the Hint Server is not information 329 solicited from individual ISPs but the AS number and district 330 information, which are more or less already public. Routing tables 331 are not generated. Instead, peers within the same ISP or the same 332 district are selected with higher priority in order to confine 333 traffic to within the same ISP or the same district. 335 When the Hint Server receives an IP address, it returns its attribute 336 information, to achieve the above. A peer can select a peer based on 337 the returned information. This operation is called GetLocation. 338 However, in preparation for the time when it becomes necessary to 339 hide topology information, an interface is provided through which a 340 priority order is returned in response to an input of a list of 341 candidate peers. This operation is called PeerSelection. 343 Although the priority node is selected based on the criterion that it 344 is within the same ISP or the same district, this type of selection 345 is not very effective if the number of participating peers is small. 346 Table 1 shows ratio of peers within the same AS or the same 347 prefecture calculated from the distribution of ASs and prefectures in 348 the IP address space from one-day data on a Winny network. 350 +--------------------+--------+ 351 | Conditions | ratio | 352 +--------------------+--------+ 353 | AS matches | 6.70% | 354 | Prefecture matches | 12.76% | 355 | Both match | 2.09% | 356 | Neither match | 78.45% | 357 +--------------------+--------+ 359 Table 1: AS and prefecture distributions 361 Since, in addition to the above, the presence/absence of content 362 affects the result, the control of selecting a peer within the same 363 district may be inadequate. Therefore, it is necessary to introduce 364 the weight of a continuous quantity that reflects the physical 365 distance or the AS path length as an indicator of the proximity of 366 the areas involved. 368 In consideration of the above, the following two measures are used 369 for the evaluation of proximity between peers in a Hint Server. 371 o AS path length (distance between ISPs) 373 Distances between peers are weighted using the degree of paths' 374 matching from an origin AS to ASs that target peers belong to. 375 The degree of paths' matching means ratio of common paths from an 376 origin AS (for example, 4/6 between A-B-C, and A-B-D, 6/8 between 377 A-B-C-D and A-B-C-E). In this year, the OCN is used as an origin 378 AS. Distance is calculated as int((1.0- degree of matching of AS 379 paths)*15). Distance is 15 if either of AS path is indefinite, 380 and is 0 if there is a perfect match. 382 o Physical distance 384 Distances between peers are measured using physical distance of 385 prefectural capitals that target peers belong to. The distance 386 between prefectural capitals is used to calculate physical 387 distance. Distances between prefectural capitals are sorted into 388 ascending order, and then into bands, with weights 1 to 15 389 assigned to them so that there are a more or less equal number of 390 "capital pairs" in each band. If either of their location is 391 indefinite, distance is equal to 15 and, if they are in the same 392 prefecture, distance is equal to 0. 394 Evaluation of distances between peers showed that the distribution 395 of distances was almost uniform when distances between peers are 396 normalized. This result suggests that using normalized distances 397 expands the area where the control by a Hint Server is effective. 399 An example of the request and the response 401 o Request 403 POST /PeerSelection HTTP/1.1 404 Host: ServerName 405 User-Agent: ClientName 406 Content-Type: text/plain; charset=utf-8 408 v=Version number 409 [application=Application identifier] 410 ip=IP address of physical interface 411 port=Port number of physical interface 412 [nat={no|upnp|unknown}] 413 [nat_ip=Global IP address using UPnP] 414 [nat_port= Global port number using UPnP] 415 [trans_id=transcation ID] 416 [pt=Flag of port type] 417 [ub=upload bandwidth] 418 [db=download bandwidth] 420 o Response 422 HTTP/1.1 200 OK 423 Date: Timestamp 424 Content-Type: text/plain; charset=utf-8 425 Cache-control: max-age=max age 426 Connection: close 428 v=Version number 429 ttl=ttl 430 server=hint server name 431 ... 432 trans_id=transaction ID 433 pt=Flag of port type 434 client_ip=Peer IP address observed from server 435 client_port=Peer port number observed from server 436 numpeers=number of respond peer 437 n=[src address] dst address / cost / option 439 4.3. Difference between P4P and Hint Server technology 441 To explain difference between P4P and Hint Server technology, the 442 architecture proposed by P4P is described. P4P aims to control 443 traffic in such a way that traffic is confined within the same 444 district or AS. As shown in Figure 2, iTracker provides an interface 445 for P2P content delivery using appTracker and peers in BitTorrent. 446 This arrangement provides a framework for efficient control based on 447 network information. 449 In this framework, it is proposed that ISPs and applications share 450 the following types of information through iTracker: 452 o Info: information about peers within an ISP 454 - ASID AS number 456 - Group number of PID node (peer) 458 - LOC: virtual and geographical coordinates 460 o Policy: information about policy on usage specified by an ISP 462 - Ratio between outgoing traffic and incoming traffic that flows 463 between domains 464 - Desirable daily traffic variation pattern on a link 466 - Specifications about relations between peer groups (PID) 468 o Capability: information about the capability of an ISP 470 - Information about usable service classes 472 - Information about the cache server 474 Note that [6] reports on the results of a field test in which it was 475 attempted to reduce overall traffic by using the above concept to 476 confine traffic exchange destinations to within the same ISP or the 477 same city. It reports that, in an evaluation with a Verizon network, 478 traffic to locations outside an ISP was reduced by 30 to 50% and that 479 the ratio of inter-city traffic to Verizon's total traffic was more 480 or less halved. 482 ISP 483 +------------------------+ Internet 484 | +----------------+ | +------------+ 485 | | iTracker | | | appTracker | 486 | | *Info |--------> +------------+ 487 | | *Policy | | ^ 488 | | *capability | | | 489 | +----------------+ | | 490 | | | 491 | +----------------+ | | 492 | | Peer |----------------+ 493 | +----------------+ | 494 +------------------------+ 496 Figure 2 498 Comparing P4P with Hint Server technology, the following three 499 differences are observed: 501 o Target of optimization: 503 P4P technology focuses on optimization within an ISP, while Hint 504 Server technology focuses on optimization in backbone traffic. 506 o Target applications: 508 P4P technology focuses on supporting BitTorrent, while Hint Server 509 technology does not specify any P2P applications. 511 o Strength of cooperation between P2P providers and ISPs: 513 P4P technology requires close cooperation between ISPs and P2P 514 providers, while Hint Server technology does not require. 516 4.4. Difference between ALTO and Hint Server technology 518 ALTO technology is more general approach than P4P technology. And 519 Hint Server technology has more similar focus of this technology. 521 Hint Server offers similar information of ALTO service and can easily 522 supports following ALTO Services. 524 o Map Service 526 The cost type is computed by physical distance and AS path length, 527 and the mode is numerical. 529 PID information, it is same as AS and physical location, does not 530 offered to client. 532 o Map Filtering Service 534 o Endpoint Cost Service 536 Hint Server only offers map information associated with requested 537 IP addresses. 539 ALTO framework has more generality but the following two points are 540 not sufficiently improved or some operational solution should be 541 offered. 543 o Target of optimization: 545 ALTO technology focuses on optimization within an ISP, while Hint 546 Server technology focuses on optimization in backbone traffic. 548 o Strength of cooperation between P2P providers and ISPs: 550 ALTO technology requires close cooperation between ISPs and P2P 551 providers, while Hint Server technology does not require. 553 5. High-Level Trial Results 554 5.1. Peer Selection with P2P 556 Table 2 shows the result of the analysis of communication in a node 557 of an ISP installed in Tokyo, as an example of measurement results. 559 +-----------------------------------------+------------+------------+ 560 | Conditions | Experiment | Experiment | 561 | | 1 | 2 | 562 +-----------------------------------------+------------+------------+ 563 | *Peers selected within the same ISP | 22% | 29% | 564 | *Peers selected within the same | 19% | 23% | 565 | district | | | 566 | *Peers selected within the same | 5% | 7% | 567 | district and the same ISP | | | 568 +-----------------------------------------+------------+------------+ 570 Table 2: Percentage of communication within the same ISP 572 The table shows that the probability of communication with peers in 573 the same ISP is proportional to the number of population and the 574 share of the ISP in each district. The data show that peers were 575 selected at random. Note that the vendor of a P2P application used 576 in this experiment explained that the mechanism of selection a peer 577 using network information can be implemented. However, peer 578 selection is normally based on past information because users often 579 cannot actually perceive the effect of using network information. 581 5.2. Peer Selection with the Hint Server 583 Since the main objective of this experiment was to verify the 584 operations of the Hint Server and P2P applications, the degree to 585 which traffic in the network was actually reduced was not evaluated. 586 However, the distances between a dummy node and a peer were obtained 587 from data on the dummy nodes. An examination of the distances 588 between a dummy node and a peer revealed that mean value of distance 589 after the Hint Server was introduced was reduced by 10% and that 95% 590 value of that was reduced by 5%. 592 6. Next steps 594 This document has reported on activities aimed at achieving 595 cooperative control between the P2P/overlay network and the network 596 infrastructure. Specifically, it has described issues to be 597 addressed and the activities of the P2P Network Experiment Council in 598 Japan, which was established to address these issues. It has also 599 introduced the Council's activities, from 2007 to 2008, focusing on 600 the use of a Hint Server, which is a feature of the traffic 601 engineering mechanism proposed by the Council. 603 The P2P Network Experiment Council has been renamed the Advanced 604 Network Use Promotion Council. The new Council aims to create new 605 network services suitable for the broadband environment and to 606 promote the widespread use of such services in rural areas. It has 607 expanded its scope of work to include all cache technologies, 608 including P2P technology. It will promote more advanced use of the 609 network by encouraging an exchange of views among a broad spectrum of 610 parties on how to use the network effectively, and by supporting a 611 variety of feasibility tests. 613 The Council aims to continue the analysis of the experiment results 614 obtained, and further study by involving a wider spectrum of P2P 615 providers, network providers and delivery service providers. 617 7. Feedback to ALTO WG 619 This section describes what the authors learned with this experiment 620 would be useful for the ALTO WG. 622 7.1. Harmonizing a Hint Server with ALTO 624 As described before, a Hint Server control mechanism focuses on 625 control between ISPs, while ALTO does control within an ISP. 626 Generally speaking, control mechanism that a peer chooses a replica 627 from its neighbors shows higher performance when probability of a 628 peer having a content is higher. This means ISP cooperation 629 mechanism that enlarges area in choosing peers will have much impact 630 on P2P performance. The authors consider combination of these two 631 mechanisms produce better P2P performance. The authors propose 632 hierarchical structure to harmonize a Hint Server with ALTO. From 633 viewpoint of cooperation between ISPs, fine information is not 634 necessarily required and it is difficult to exchange fine information 635 between ISPs. Considering this situation, the authors use only 636 coarse information to control backbone traffic in the experiments 637 this year, though demand of controlling traffic within an ISP using 638 fine information will arise in the near future. The authors consider 639 that introducing hierarchical structure into ALTO is necessary to 640 cope with both situations. Actually, the authors plan to try a 641 hierarchical control mechanism in the next steps, which include the 642 following two steps. 644 o In the first step, coarse information about whole the network is 645 used to select ISPs. 647 o Next, fine information within the ISP is used to select a peer. 649 7.2. Measurement mechanism 651 In experiments, there were two difficulties as follows: 653 o Evaluating effect of introducing a Hint Server was difficult, 654 since P2P applications had their own measurement mechanisms. 656 o How to treat priority orders of peers suggested by a Hint Server 657 could not be predetermined for P2P applications. 659 From these experiences, the authors consider that clarifying 660 requirements about measurement mechanisms for P2P applications are 661 necessary also in Alto. 663 8. Security Considerations 665 There are no security considerations in this document. 667 9. IANA Considerations 669 No need to describe any request regarding number assignment. 671 10. Acknowledgments 673 These experiments were performed under cooperation among P2P Network 674 Experiment Council members, and DREAMBOAT co.,ltd., Bitmedia Inc., 675 Utagoe. Inc. and Toyama IX have especially supported analyses of the 676 experimernts. The authors appreciate Tohru Asami, Hiroshi Esaki and 677 Tatsuya Yamshita for their constructive comments. 679 11. Informative References 681 [1] Hiroshi Esaki, "The State of Traffic and the Effects of P2P", 682 Special Symposium on Broadband, September 2008 (in Japanese). 684 [2] Yoichi Yamazaki, "ISPs have Begun to Explore Tomorrow due to the 685 Expansion of Traffic", Nikkei Communications, December 2007 (in 686 Japanese). 688 [3] TVBank, "Live Delivery using `BB Broadcast'Achieving 96% Saving 689 in Traffic!", http:.wwww.tv-bank.com/jp/20081031.html, 2008 (in 690 Japanese). 692 [4] Ministry of Internal Affairs and Communications, "Disclosure of 693 the Report `Working Group on P2P Networks'", 694 http://www.soumu.go.jp/menu_news/s-news/2007/070629_11.html, 695 2007 (in Japanese). 697 [5] The Foundation for MultiMedia Communications, "The P2P Network 698 Experiment Council", http://www.fmmc.or.jp/P2P/about.htm, 2007 699 (in Japanese). 701 [6] Open P4P, "P4P Field Tests: Yale-Pando-Verizon", 702 http://www.openp4p.net/front/fieldests, 2009. 704 Authors' Addresses 706 Satoshi Kamei 707 NTT Service Integration Laboratories 708 3-9-11, Midori-cho 709 Musashino-shi, Tokyo 180-8585 710 JP 712 Phone: +81-422-59-6942 713 Email: kamei.satoshi@lab.ntt.co.jp 715 Tsuyoshi Momose 716 Cisco Systems G.K. 717 2-1-1 Nishi-Shinjuku 718 Shinjuku-ku, Tokyo 163-0409 719 JP 721 Phone: +81-3-5324-4154 722 Email: tmomose@cisco.com 724 Takeshi Inoue 725 NTT Communications 726 3-4-1, Shibaura 727 Minato-ku, Tokyo 108-8118 728 JP 730 Phone: +81-3-6733-7177 731 Email: inoue@jp.ntt.net 732 Tomohiro Nishitani 733 NTT Communications 734 1-2-20, Shibaura 735 Minato-ku, Tokyo 108-8118 736 JP 738 Phone: +81-50-3812-4742 739 Email: tomohiro.nishitani@ntt.com