idnits 2.17.1 draft-kamei-p2p-experiments-japan-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2012) is 4183 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PRG S. Kamei 3 Internet-Draft NTT Communications 4 Intended status: Informational T. Momose 5 Expires: April 18, 2013 Cisco Systems 6 T. Inoue 7 T. Nishitani 8 NTT Communications 9 October 15, 2012 11 ALTO-Like Activities and Experiments in P2P Network Experiment Council 12 draft-kamei-p2p-experiments-japan-09 14 Abstract 16 This document introduces experiments to clarify how ALTO-like 17 approach was effective to reduce network traffic made by a Council in 18 Japan to harmonize P2P technology with the infrastructure. And this 19 also provides some suggestions that might be useful for ALTO 20 architecture learned through our experiments. Especially, experiment 21 for application independent ALTO-like server operation. 23 Status of this Memo 25 This Internet-Draft is submitted 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). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 18, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Background in Japan . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. P2P traffic . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Impact on network infrastructure . . . . . . . . . . . . . 4 61 2.3. The object of P2P Network Experiment Council . . . . . . . 5 62 3. The object of P2P Network Experiment Council . . . . . . . . . 5 63 4. The details of the experiments . . . . . . . . . . . . . . . . 7 64 4.1. Dummy Node . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Hint Server ('08) . . . . . . . . . . . . . . . . . . . . . . 8 66 6. High-Level Trial Results . . . . . . . . . . . . . . . . . . . 13 67 6.1. Peer Selection with P2P . . . . . . . . . . . . . . . . . 13 68 6.2. Peer Selection with the Hint Server . . . . . . . . . . . 13 69 7. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 14 70 7.1. Next steps . . . . . . . . . . . . . . . . . . . . . . . . 14 71 7.2. Feedback to ALTO WG . . . . . . . . . . . . . . . . . . . 15 72 7.2.1. Hierarchical architecture for ALTO servers . . . . . . 15 73 7.2.2. Measurement mechanism . . . . . . . . . . . . . . . . 15 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 77 11. Informative References . . . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 An overlay network, which is used by P2P and other applications, 83 offers the advantage of allowing flexible provision of services while 84 hiding the lower layer network. The downside is that inefficient 85 routes are often taken in the lower IP network, thereby increasing 86 the network load. Several proposals have been made to build an 87 overlay network that takes account of the information about the lower 88 layer network. [1] [2] Since the management of the Internet is highly 89 distributed, it is difficult to implement such proposals and thus 90 optimize a network without the cooperation of network providers. 92 Recently, the controversy between the overlay network and the network 93 providers about network resource wastefulness has been rekindled. 94 Under these circumstances, some researchers have studied overlay 95 network control technology that takes account of the network topology 96 information obtained from network providers. 98 One of the activities concerning this issue has been made by the P2P 99 Network Experiment Council in Japan. We planned some experiments in 100 the council. This document reports on the issues addressed and 101 experiments being made by the council. 103 This experiment made from 2007 to 2008, because P2P traffic had 104 reduced due to rivision of copyright law in Japan. And recently, 105 dominant traffic is HTTP based flash streaming in Japan, U.S, and so 106 on. However, P2P traffic remains in large traffic, like PPStreaming, 107 in Asia (except Japan)[3], and P2P technology is very userful in such 108 a realtime streaming area. 110 Our experience in this experiment might be useful for ALTO 111 architecture, especially for application independent and multi 112 application ALTO-like server operations. We suggest that generic 113 measurement mechanism is important because each application has 114 different mechanism and it is difficult to compare the effectiveness. 116 This document is a product of the P2P RG. The views in this document 117 were considered controversial by the P2P RG but the RG reached a 118 consensus that the document should still be published. 120 2. Background in Japan 122 2.1. P2P traffic 124 As of 2008, the world most popular P2P file sharing application, 125 Bittorrent, isn't widely deployed in Japan. Instead, other Japan 126 specific file sharing P2P applications such as Winny [4], Share [5], 127 and so on, still occupy 40% of the Internet traffic in Japan even 128 though many those P2P users were arrested for sharing illegal files 129 with these P2P apps. 131 Each P2P file sharing application has a unique protocol and none of 132 them have a large market share therefore making it hard to 133 effectively control. 135 2.2. Impact on network infrastructure 137 One of the advantage of using P2P technology for content delivery is 138 that peers exchange content directly among themselves without server 139 bottleneck. This reduces the load on servers. Also, P2P 140 applications can reduce upstream traffic from an origin content 141 server. This reduce server cost dramatically. 143 It is also known that server cost could be reduced with P2P 144 technology. However, the story is quite different for network 145 providers. From the viewpoint of network providers, the traffic that 146 content servers generate has shifted to the edge network and the 147 amount of traffic has not necessarily been reduced with using P2P 148 technology for reducing server cost. Another problem for network 149 providers that an extremely inefficient routing may be selected has 150 been raised. It is because overlay network systems are configured 151 without any regard to the structure of the lower layer network or 152 network geometry. 154 In some cases, the total amount of traffic on the Internet used to be 155 limited by the capacity of servers. For those cases, P2P technology 156 can improve the scalability of servers , however it may exhaust 157 network resources. Moreover, using P2P applications increases the 158 volume of traffic per user remarkably. 160 Faced with increase in the load on network infrastructure, network 161 providers are compelled to take actions to overcome the sudden 162 increase in facilities' cost. Representative actions include placing 163 content in internet exchanges or data centers, introducing bandwidth 164 control, and raising the access fees [6]. 166 However, current dominant traffic is HTTP based flash streaming in 167 Japan, U.S, and so on. However, P2P traffic remains in large 168 traffic, like PPStreaming, in Asia (except Japan)[3], and P2P 169 technology is very userful in such a realtime streaming area. The 170 increase in traffic arising from such a shift may be a great threat 171 to the network. 173 2.3. The object of P2P Network Experiment Council 175 In order to reduce Internet traffic and encourage legitimate use of 176 P2P technologies, the Japanese government led to establish a new 177 council called P2P Network Experiment Council conjunction with 178 commercial P2P application vendors and ISPs in 2006. 180 Then the council had started to develop regulations that include 181 several guidelines such like an advance notice to restrict bandwidth 182 to heavy traffic users. In accordance with the regulations, some 183 ISPs introduced solutions that reduce traffic caused by P2P file 184 sharing applications. 186 Besides this activity, the council also looked for new ways to 187 control traffic by commercial P2P applications with ISPs, carriers, 188 contents providers and P2P system vendors. In this work, the council 189 had experiments that introduced ALTO-like system and observed how the 190 traffic was reduced by redirecting to proper peers on the real 191 Internet in Japan. 193 In our experiment, the council deployed hint servers, which are 194 described in section 4. Hint servers have a protocol offering 195 network distance to peers, which is disclosed to P2P application 196 vendors. 198 Using hint server, P2P application vendors can introduce ALTO 199 concepts easily to their P2P distribution systems. Because the 200 protocol provided of hint servers is independent on specific P2P 201 application vendors like Bittorrent, the council defines the protocol 202 to be able to use any P2P application vendors. It needs to gather 203 network information from ISPs to offer network distance to peers, 204 however many ISPs dislike to disclose such information to others. 205 Therefore, hint servers are designed to offer little information 206 about ISPs' network architecture to P2P application vendors. 208 To monitor traffic of peers, the council also deployed dummy node, 209 which are described in section 3.1. 211 This memo describes the overview of the experiments. 213 3. The object of P2P Network Experiment Council 215 Ministry of Internal Affairs and Communications Japan, which has 216 jurisdiction over information and communication systems in Japan, 217 held meetings of an advisory panel on network neutrality from 2006 to 218 2007 in order to study issues related to next generation networks, 219 such as how to ensure fairness in the use of networks and how to 220 define fairness in cost burden. The panel took an interest in P2P 221 technology as a solution to the impending traffic saturation in the 222 backbone network resulting from the rapid expansion of broadband 223 access in Japan, and formed a "Working Group on the P2P Network", 224 which carried out an intensive study of P2P networks. 226 The Working Group reported that it is necessary to undertake the 227 following four activities, which are intended to encourage the 228 government to adopt relevant policies [7]: 230 o Formulate guidelines to be self-imposed by the industry on P2P 231 file delivery applications, 233 o Promote feasibility tests of P2P networks, 235 o Study the current state of traffic control and promote the sharing 236 of information, 238 o Hold working group meetings on traffic control. 240 The first two proposals led to the establishment of the P2P Network 241 Experiment Council supported by Ministry of Internal Affairs and 242 Communications Japan [8]. The Council, with membership from P2P 243 delivery providers, content holders, and network providers, began a 244 variety of delivery experiments, which were expected to strengthen 245 cooperative control between different layers. In contrast to P4P, 246 which takes a relatively top-down approach of adopting architecture 247 based on a proposal from a university, the Council is characterized 248 by its bottom-up approach. The aim of establishing the Council has 249 been described as follows. 251 The rapid growth of broadband access enables content delivery 252 system to deliver high-quality and high-volume videos securely and 253 efficiently. Although P2P technology is an effective technology 254 for this requirement, it still has some issues to be coped with. 255 Therefore, the "P2P Network Experiment Council" was established 256 with the support of the Japanese Ministry of Internal Affairs and 257 Communications with its secretariat set up within the Foundation 258 for MultiMedia Communications (FMMC) in order to formulate 259 guidelines for providers and conduct feasibility tests so that 260 users can receive video delivery services safely. 262 The activities of the P2P Network Experiment Council can be 263 classified into two categories. The first is activities to formulate 264 guidelines for the promotion of the commercial use of P2P technology. 265 These will enable users to use P2P technology safely, and providers 266 to have clear rules they must observe. The other is feasibility 267 tests of P2P technology. The next section describes mainly 268 experiments conducted from 2007 to 2008. 270 4. The details of the experiments 272 The council has already learned that the server cost could be reduced 273 with using P2P technology for contents delivering by investigating 274 data offered by the members of the council. For example, the data 275 brought by the vendors shows as follows: 277 90% of traffic was reduced with UG Live by Utagoe Inc [9]. 279 The costs of delivering to tens of thousand subscribers was 280 reduced to 1/5 with BBbroadcast with TV Bank Corp. [10] 282 On the other hand, these reduced server costs may affect network 283 load. One of the goals of our experiments was to visualize the 284 impacts and propose an architecture to reduce network load caused by 285 these new technologies. 287 In order to visualize the reduction of network cost, we had to 288 modelize P2P applications and multi-ISP environment. It will also 289 needed for visualizing the effectiveness of ALTO-like approach. 291 4.1. Dummy Node 293 As mentioned before, while the effect of delivery using P2P 294 technology on reducing the traffic and the load on servers is well 295 known, traffic behavior in the inter-ISP is not known. In Japan, 296 there is a backbone traffic report cooperated with ISPs and IXes 297 [11]. However, this measurement requires to capture packets on 298 subscribers line to know end user's activity. It is not realistic to 299 measure the behavior of P2P applications at user terminals connected 300 to the Internet because that would require a large-scale arrangement 301 for measurement, such as using Deep Packet Inspection (DPI) on 302 aggregated lines. 304 To solve these problems, we put several nodes called 'dummy nodes' in 305 the ISP's networks. The dummy nodes emulate an end user's PC and P2P 306 applications are running on the nodes. Every P2P node provided by 307 participating vendors in the experiment was configured so it always 308 contacted the hint server. 310 By introducing dummy nodes, we can observe and evaluate how much P2P 311 applications have affected networks by measuring the traffic on dummy 312 nodes. Since this method can't measure every subscriber's traffic, 313 the accuracy would be less than other methods. But this make it 314 possible to adapt to situations many different P2P applications 315 coexist on a network. We can say this is suitable for these 316 experiments. 318 A dummy node consists of Intel PC server, Linux(CentOS), VMWare and 319 Windows XP works on VMWare. With this configuration, all packets can 320 be captured without any impacts to the network, nodes and application 321 behaviors. And it enable us to use different P2P applications for 322 windows and evaluate them generally. 324 To see behaviors of the node, incoming and outgoing packets are 325 captured on Linux because every packets are transmitted through it. 326 In these experiments, we captured source/destination address, port 327 number, amount of traffic and start/end time to see flow information. 329 60 Dummy nodes are put on access networks that are closest subscriber 330 as possible in different 40 ISP networks. 332 +----------------------+ 333 |+--------------------+| 334 ||+------------------+|| 335 ||| P2P Application ||| 336 ||| WindowsXP ||| 337 ||| +--+ ||| 338 ||+--------|N |------+|| 339 || VMware |e | || 340 |+---------|t |-------+| 341 | Linux |IF| capture| 342 +----------| |--------+ 343 +--+ 345 Dummy nodes 347 Figure 1 349 5. Hint Server ('08) 351 In Japan, bottleneck in IP networks have been shifting from access 352 networks to backbone networks and equipments, such as bandwidth 353 between ISPs and capacity in IXs, since FTTH has rapidly spread all 354 over Japan. Under these circumstances, the Council proposed a less 355 restrictive and more flexible cooperation between ISPs than existent 356 P4P experiments [12]. The proposed method consists of the following 357 elements: (1) P2P clients, (2) P2P control servers, and (3) a hint 358 server: a peer selection hint server. (1) and (2) are existing 359 systems but whether (2) exists depends on each application. (3) is a 360 server that provides a hint as to the selection of a peer, and plays 361 a role equivalent to that of ALTO Server. Note that this proposal 362 was based on results of experiments using dummy nodes. The results 363 showed that it was possible to reduce unnecessary traffic that flows 364 across the boundaries of geographical districts or ISPs through 365 providing information about the physical network to P2P applications. 367 When a peer joins the network, it registers its location information 368 (IP address) and supplementary information (line speed, etc.) with&# 369 12288;the hint server. The hint server calculate network distance 370 between peers (P2P client) based on network topology information 371 obtained from the ISP and generates a priority table for peer 372 selection. The hint server returns the table to the peer. 374 If all information can be made publicly, the above procedure can 375 produce a result which is close to overall optimization. However, 376 some information held by ISPs can often be confidential. Besides, in 377 some cases, the volume of calculation required to process all 378 information can be excessive. To avoid these problems, it is planned 379 to conduct experiments with a limited set of functions, analyze 380 experiments results, and gradually expand the scope of optimization. 382 A control mechanism that makes use of all possible information is 383 difficult not only technically but also difficulties to achieve 384 coordination among providers. In consideration of these 385 difficulties, the council has been limiting the implementation and 386 experiments to the following scope since 2006. 388 Figure 2 shows an outline of the hint server. 390 +---------+ GetLocation +-------------GeoIP DB Server---------+ 391 | | +-----------+ | +----------+ +-----------+ | 392 | |--|IP Address |-->| | GeoIP DB | |Quagga etc | | 393 | | +-----------+ | +----------+ +-----------+ | 394 | | | +-------------+ +----------------+ | 395 | | +-----------+ | | District | | Routing | | 396 | |--|AS Code: |---| | information | |information(DGP)| | 397 | | |Regional | | | | | | | 398 |P2P Peers| |Information| | | Range of | |AS Code(origin) | | 399 | or | +-----------+ | | IP address | | | | 400 | Contro| | | +-------------+ +----------------+ | 401 | Server | +-------------------------------------+ 402 | | | ^ 403 | | PeerSelection v | 404 | | +-----------+ +--------------------------------------+ 405 | |--|IP Address |-->| +--Priority Node Selection System--+ | 406 | | | List | | | | | 407 | | +-----------+ | | Peer candidate ranking | | 408 | | +-----------+ | | | | 409 | |--| Ranking |-->| +----------------------------------+ | 410 | | +-----------+ +--------------------------------------+ 411 +---------+ 413 Peer selection hint server 415 Figure 2 417 The network information used by the hint server is not information 418 solicited from individual ISPs but the AS number and district 419 information, which are more or less already public. Routing tables 420 are not generated. Instead, peers within the same ISP or the same 421 district are selected with higher priority in order to confine 422 traffic to within the same ISP or the same district. 424 When the hint server receives an IP address, it returns its attribute 425 information, to achieve the above. A peer can select a peer based on 426 the returned information. This operation is called GetLocation. 427 However, in preparation for the time when it becomes necessary to 428 hide topology information, an interface is provided through which a 429 priority order is returned in response to an input of a list of 430 candidate peers. This operation is called PeerSelection. 432 Although the target node is selected based on the criterion that it 433 is within the same ISP or the same district, this type of selection 434 is not very effective if the number of participating peers is small. 435 Table 1 shows ratio of peers within the same AS or the same 436 prefecture calculated from the distribution of ASs and prefectures in 437 the IP address space from one-day data on a Winny network. 439 +--------------------+--------+ 440 | Conditions | ratio | 441 +--------------------+--------+ 442 | AS matches | 6.70% | 443 | Prefecture matches | 12.76% | 444 | Both match | 2.09% | 445 | Neither match | 78.45% | 446 +--------------------+--------+ 448 Table 1: AS and prefecture distributions 450 Since, in addition to the above, the presence/absence of content 451 affects the result, the control of selecting a peer within the same 452 district may be inadequate. Therefore, it is necessary to introduce 453 the weight of a continuous quantity that reflects the physical 454 distance or the AS path length as an indicator of the proximity of 455 the areas involved. 457 In consideration of the above, the following two measures are used 458 for the evaluation of proximity between peers in a hint server. 460 o AS path length (distance between ISPs) 462 AS path length calculated from BGP full routes. Since a full 463 routing table retrieved at an ISP can show only a best path, it 464 may not get an accurate length if the AS hop of both ISPs is too 465 large. To avoid this, we use multiple BGP information received 466 from different ISPs and combine them. Based on this concept, we 467 used BGP routing information's offered by three ISPs operated by 468 big telecommunication couriers and made a topology tree. Then it 469 enables to calculate the shortest path between given two ASes. 471 o Geographical distance 473 Distances between peers are measured using physical distance of 474 prefectural capitals that target peers belong to. The distance 475 between prefectural capitals is used to calculate physical 476 distance. Distances between prefectural capitals are sorted into 477 ascending order, and then into bands, with weights 1 to 15 478 assigned to them so that there are a more or less equal number of 479 "capital pairs" in each band. If either of their location is 480 indefinite, distance is equal to 15 and, if they are in the same 481 prefecture, distance is equal to 0. 483 Evaluation of distances between peers showed that the distribution 484 of distances was almost uniform when distances between peers are 485 normalized. This result suggests that using normalized distances 486 expands the area where the control by a Hint Server is effective. 488 The geographical distance is only used when the AS path length is 489 same. 491 An example of the request and the response 493 o Request 495 POST /PeerSelection HTTP/1.1 496 Host: ServerName 497 User-Agent: ClientName 498 Content-Type: text/plain; charset=utf-8 500 v=Version number 501 [application=Application identifier] 502 ip=IP address of physical interface 503 port=Port number of physical interface 504 [nat={no|upnp|unknown}] 505 [nat_ip=Global IP address using UPnP] 506 [nat_port= Global port number using UPnP] 507 [trans_id=transcation ID] 508 [pt=Flag of port type] 509 [ub=upload bandwidth] 510 [db=download bandwidth] 512 o Response 514 HTTP/1.1 200 OK 515 Date: Timestamp 516 Content-Type: text/plain; charset=utf-8 517 Cache-control: max-age=max age 518 Connection: close 520 v=Version number 521 ttl=ttl 522 server=hint server name 523 ... 524 trans_id=transaction ID 525 pt=Flag of port type 526 client_ip=Peer IP address observed from server 527 client_port=Peer port number observed from server 528 numpeers=number of respond peer 529 n=[src address] dst address / cost / option 531 6. High-Level Trial Results 533 6.1. Peer Selection with P2P 535 Table 2 shows the result of the analysis of communication in a node 536 of an ISP installed in Tokyo, as an example of measurement results. 538 In these two experiments we evaluate different P2P applications, in 539 1st experiment, the P2P topology is generated by tree algorithm, and 540 in 2nd experiment, it is generated by mesh algorithm. Both of them 541 result in similar performance. 543 +-----------------------------------------+------------+------------+ 544 | Conditions | Experiment | Experiment | 545 | | 1 | 2 | 546 +-----------------------------------------+------------+------------+ 547 | *Peers selected within the same ISP | 22% | 29% | 548 | *Peers selected within the same | 19% | 23% | 549 | district | | | 550 | *Peers selected within the same | 5% | 7% | 551 | district and the same ISP | | | 552 +-----------------------------------------+------------+------------+ 554 Table 2: Percentage of communication within the same ISP 556 The table shows that the probability of communication with peers in 557 the same ISP is proportional to the number of population and the 558 share of the ISP in each district. The data show that peers were 559 selected at random. Note that the vendor of a P2P application used 560 in these experiments explained that the mechanism of selection a peer 561 using network information can be implemented. However, peer 562 selection is normally based on past information because users often 563 cannot actually perceive the effect of using network information. 565 6.2. Peer Selection with the Hint Server 567 The main objective of these experiments was to verify the operations 568 of the hint server and P2P applications. The distances between a 569 dummy node and a peer were obtained from data on the dummy nodes. An 570 examination of the distances between a dummy node and a peer revealed 571 that mean value of distance after the hint server was introduced was 572 reduced by 10% and that 95th percentile was reduced by 5%. The 573 results show introducing hint server can reduce network loads by P2P 574 applications. 576 7. Considerations 578 We clarified followings throughout our experiments. 580 1. Dispersed dummy nodes can figure out the behavior of peers and 581 traffic between inter-ISP networks, which peers are selected by 582 each peer. Therefore it proves that the importance of peer 583 selection control mechanism proposed in ALTO. 585 2. Using our peer selection control mechanism, called hint server, 586 could achieve significant differences. Our hint server can lead 587 each peer to select nearer peer. 589 3. The result of 10% reduction of network cost is not satisfying 590 effect for ISPs, but the controllability for P2P applicationis 591 most important point. When they apply this mechanism for their 592 real ISP network, they will set very large cost for most 593 expensive network link. 595 In the experimental result of peer selection control, it is smaller 596 in intra-ISP traffic than other experiments [13] We think that it is 597 because there are smaller peers in each area of traffic control. 598 When there are many peers in one ISP, it is easy to select peers in 599 the same ISP. However, when there are small peers in one ISP, it is 600 difficult to select peers in the same ISP. In the situation of our 601 experiments, there are many ISPs of peers belonging, and there are 602 relatively smaller peers exist in same ISP. 604 Moreover, we didn't force P2P vendors to limit their implementation 605 policy, therefore we can observe differences how each implementations 606 weigh the information from the hint servers. Especially, in tree 607 overlay topology P2P applications, such mechanism is very effective, 608 on the other hand, in mesh overlay system, less effective. 610 7.1. Next steps 612 Recent research, we've changed the communication protocol to hint 613 servers to ALTO based because it is nearly standardized. In our 614 implementation, PIDs and the value of cost are mapped to ISP subnets, 615 and ISP distance respectively. We also implement services for 616 compatibility required by ALTO such as Service Capability and Map 617 Services. But the Endpoint Cost Service is mainly used because of 618 backward compatibility of our experiments. 620 We also study hierarchical hint server structure, in order to control 621 in coarse inter-ISPs and in detail intra-ISP. It is also effective 622 for limiting the area of information disclose. 624 7.2. Feedback to ALTO WG 626 This section describes what the authors learned with these 627 experiments would be useful for the ALTO WG. 629 7.2.1. Hierarchical architecture for ALTO servers 631 In our experiments, we present the possibility of traffic control 632 among multi-ISPs and multi-P2P applications using ALTO mechanism. On 633 the other hand, we found several problems in ISP operations to adapt 634 the mechanism. One is the granularity of network information from 635 council members. Among inter-ISP area, it is relatively easy to 636 treat information for public purpose using BGP full route. On the 637 other hand, among intra-ISP area, it may be difficult to disclose 638 private information of each ISP. [14] propose some modification for 639 ALTO protocol in order to hide ISP information. We propose 640 hierarchical structures. From the viewpoint of cooperation between 641 ISPs, fine-grained information is not necessarily required and 642 moreover it is difficult to exchange the fine-grained information 643 between ISPs. Considering this situation, the authors use only 644 coarse-grained information to control backbone traffic in this 645 experiments, though demand of controlling traffic within an ISP using 646 fine-grained information may arise in future. Therefore it led us 647 that introducing hierarchical structure into ALTO is necessary to 648 cope with both situations. Actually, to adapt a hierarchical control 649 mechanism which include the following two steps will be useful. 651 o In the first step, coarse-grained information about whole the 652 network is used to select ISPs. 654 o Next, fine-grained information within the ISP is used to select a 655 peer. 657 7.2.2. Measurement mechanism 659 In the experiments, there were two difficulties as follows: 661 o Evaluating effect of introducing a hint server was difficult, 662 since P2P applications had their own measurement mechanisms. 664 o How to treat priority orders of peers suggested by a hint server 665 could not be predetermined for P2P applications. 667 From these experiences, the authors consider that clarifying 668 requirements about measurement mechanisms for P2P applications are 669 necessary also in ALTO. 671 8. Security Considerations 673 This document does not propose any kind of protocol, practice or 674 standard. 676 9. IANA Considerations 678 No need to describe any request regarding number assignment. 680 10. Acknowledgments 682 Thanks to strong support by MIC (Ministry of Internal Affairs and 683 Communications of Japanese government), the council was established. 684 These experiments were performed under cooperation among P2P Network 685 Experiment Council members, and DREAMBOAT co.,ltd., Bitmedia Inc., 686 Utagoe. Inc. and Toyama IX have especially supported analyses of the 687 experiments. The authors appreciate Tohru Asami, Hiroshi Esaki and 688 Tatsuya Yamshita for their constructive comments. 690 And the authors would like to thank Martin Stiemerling, Stefano 691 Previdi and Vijay K.Gurbani for the comments on this document. 693 11. Informative References 695 [1] R.Kawahara, E.K.Lua, M.Uchida, S.Kamei, H.Yoshino, "On the 696 Quality of Triangle Inequality Violation Aware Routing Overlay 697 Architecture", INFOCOM 2009: 2761-2765. 699 [2] Z.Li, "QRON: QoS-aware routing in overlay networks", IEEE 700 JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 22, NO. 1, 701 JANUARY 2004. 703 [3] Sandvine Corp, "Global Internet Phenomena Report: 1H 2012", 704 September 2012, 705 . 707 [4] "Winny on Wikipedia", . 709 [5] "Share on Wikipedia", 710 . 712 [6] Taniwaki, "Broadband Competition Policy in Japan", 2008, 713 . 715 [7] Ministry of Internal Affairs and Communications, "Disclosure of 716 the Report `Working Group on P2P Networks'", 717 http://www.soumu.go.jp/menu_news/s-news/2007/070629_11.html, 718 2007 (in Japanese). 720 [8] The Foundation for MultiMedia Communications, "The P2P Network 721 Experiment Council", http://www.fmmc.or.jp/P2P/about.htm, 2007 722 (in Japanese). 724 [9] Utagoe Inc., "UGLive technology introduction", 725 http://www.utagoe.com/en/technology/grid/live/index.html, 726 March, 2011. 728 [10] TVBank, "Live Delivery using `BB Broadcast'Achieving 96% Saving 729 in Traffic!", http:.wwww.tv-bank.com/jp/20081031.html, 2008 (in 730 Japanese). 732 [11] Cho, Fukuda, Esaki, and Kato, "The Impact and Implications of 733 the Growth in Residential User-to-User Traffic", SIGCOMM2006, 734 pp207-218, Pisa, Italy, September 2006. 736 [12] Open P4P, "P4P Field Tests: Yale-Pando-Verizon", 737 http://www.openp4p.net/front/, 2009. 739 [13] "RFC5632: Comcast's ISP Experiences in a Proactive Network 740 Provider Participation for P2P (P4P) Technical Trial", 741 September 2009. 743 [14] "ALTO H12,draft-kiesel-alto-h12-02 (work in progress)", March 744 2010. 746 Authors' Addresses 748 Satoshi Kamei 749 NTT Communications Corporation 750 Granpark Tower 17F, 3-4-1 Shibaura 751 Minato-ku, Tokyo 108-8118 752 JP 754 Phone: +81-50-3812-4697 755 Email: skame@nttv6.jp 756 Tsuyoshi Momose 757 Cisco Systems G.K. 758 9-7-1 Akasaka 759 Minato-ku, Tokyo 107-6227 760 JP 762 Phone: +81-3-6738-5154 763 Email: tmomose@cisco.com 765 Takeshi Inoue 766 NTT Communications 767 3-4-1, Shibaura 768 Minato-ku, Tokyo 108-8118 769 JP 771 Phone: +81-3-6733-7177 772 Email: inoue@jp.ntt.net 774 Tomohiro Nishitani 775 NTT Communications 776 1-1-6, Uchisaiwaicho 777 Chiyodaku, Tokyo 100-8019 778 JP 780 Phone: +81-50-3812-4742 781 Email: tomohiro.nishitani@ntt.com