RFC 6875

The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan

📅 published February 2013, from ietf

RFC 6875 🎀 Title Block Tea ☕

RFC 6875 is titled "The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan" 💖

It's an IRTF document, published under the Informational category in February 2013, with ISSN 2070-1721 ✨ The authors are S. Kamei (NTT Communications), T. Momose (Cisco Systems), T. Inoue (NTT Communications), and T. Nishitani (NTT Communications) 🫶 The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there 🧚

Abstract 🌸

Okay so this doc describes experiments that show how an approach similar to Application-Layer Traffic Optimization (ALTO) was effective at reducing network traffic 🔥 The P2P Network Experiment Council ran these experiments in Japan, trying to get peer-to-peer (P2P) technology and network infrastructure to play nicely together 🦋 Based on what they learned, the doc gives some suggestions that might be useful for the ALTO architecture, especially for application-independent, ALTO-like server operation 💅

Status of This Memo 🍓

This document is not an Internet Standards Track specification. It's published for informational purposes, so no, it's not a standard 🙈

It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development. Those results might not be suitable for deployment, just so you know 💀 This RFC represents the individual opinion(s) of one or more members of the Peer-to-Peer Research Group of the IRTF. Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard. For the details, see Section 2 of RFC 5741 ✨

For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6875 🌈

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 🔥

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read those carefully, bestie, because they describe your rights and restrictions with respect to this document 🫶

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Background in Japan  . . . . . . . . . . . . . . . . . . . . .  4
  2.1.  P2P Traffic  . . . . . . . . . . . . . . . . . . . . . . .  4
  2.2.  Impact on Network Infrastructure . . . . . . . . . . . . .  4
  2.3.  Overview of the P2P Network Experiment Council . . . . . .  5
3.  Objectives of the P2P Network Experiment Council . . . . . . .  6
4.  Details of the Experiment  . . . . . . . . . . . . . . . . . .  7
  4.1.  Dummy Node . . . . . . . . . . . . . . . . . . . . . . . .  7
5.  Hint Servers . . . . . . . . . . . . . . . . . . . . . . . . .  9
6.  High-Level Trial Results . . . . . . . . . . . . . . . . . . . 13
  6.1.  Peer Selection with P2P  . . . . . . . . . . . . . . . . . 13
  6.2.  Peer Selection with the Hint Server  . . . . . . . . . . . 13
7.  Considerations . . . . . . . . . . . . . . . . . . . . . . . . 14
  7.1.  Next Steps . . . . . . . . . . . . . . . . . . . . . . . . 14
  7.2.  Feedback to the ALTO WG  . . . . . . . . . . . . . . . . . 15
    7.2.1.  Hierarchical Architecture for ALTO Servers . . . . . . 15
    7.2.2.  Measurement Mechanism  . . . . . . . . . . . . . . . . 15
8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
10. Informative References . . . . . . . . . . . . . . . . . . . . 16

1. Introduction ✨

Okay so an overlay network, which P2P and other apps use, is amazing because it lets you provision services flexibly while hiding the lower-layer network 🦋 The catch is that inefficient routing that ignores the lower-layer network can end up increasing the network load 😭 Several proposals have tried to build overlay networks that take the lower-layer network's information into account [1] [2]. But the management of the Internet is highly distributed, so it's hard to implement these proposals, and to optimize a network, without cooperation from network providers 🙈

Recently, the drama between overlay networks and network providers about network resource wastefulness has come back 🔥 Because of that, some researchers have been studying overlay-network control technology that uses network topology information obtained from network providers 💅

One research effort on this issue was the set of experiments planned and performed by the P2P Network Experiment Council in Japan 🌸 This document reports on those experiments and the issues they addressed 🫶

These experiments ran from 2007 to 2008, because P2P traffic decreased after Japanese copyright law was revised 🍓 More recently, the dominant traffic in Japan, the United States, and elsewhere has been HTTP-based flash streaming. But a large amount of traffic in Asia (outside Japan) is still P2P traffic, like P2P streaming [3], and P2P technology is super useful in that real-time streaming area 🎀

Our experience in this experiment might be useful for the ALTO architecture, especially for application-independent and multi-application ALTO-like server operations 🧚 We suggest that a generic measurement mechanism is important, because each application has a different mechanism, which makes it hard to compare how effective they are 🌈

This document is a product of the P2P Research Group (RG). The views in this document were considered controversial by the P2P RG, but the RG reached a consensus that the document should still be published 💜

2. Background in Japan 🌸

2.1. P2P Traffic 🦋

As of 2008, the world's most popular P2P file-sharing app, BitTorrent, was not widely deployed in Japan 🙈 Instead, file-sharing P2P apps specific to Japan, like Winny [4] and Share [5], still accounted for 40% of the Internet traffic in Japan. This happened even though many of those P2P users were arrested for sharing illegal files with these apps 💀

Each P2P file-sharing app has its own unique protocol, and none of them has a large market share. That makes them hard to control effectively 😭

2.2. Impact on Network Infrastructure 🔥

One advantage of using P2P technology for content delivery is that peers exchange content directly among themselves, without a server bottleneck 💖 This reduces the load on servers. P2P apps can also reduce upstream traffic from an origin content server, which dramatically reduces server cost 👑

It's also known that server cost could be reduced with P2P technology. But the story is quite different for network providers 🫶 From their viewpoint, the traffic that content servers generate has shifted to the edge network, and using P2P technology to reduce server cost hasn't necessarily reduced the amount of traffic 😭 Another problem for network providers is that extremely inefficient routing may be selected, because overlay network systems are configured without any regard to the structure of the lower-layer network or network geometry 🙈

In some cases, the total amount of traffic on the Internet used to be limited by the capacity of servers. In those cases, P2P technology can improve the scalability of servers, but it may exhaust network resources 💅 Moreover, using P2P apps remarkably increases the volume of traffic per user 🌈

Faced with an increase in the load on network infrastructure, network providers are compelled to act to overcome the sudden increase in facilities' costs ✨ Representative actions include placing content in Internet Exchanges (IXs) or data centers, introducing bandwidth control, and raising access fees [6] 🍓

As mentioned above, the dominant traffic currently in Japan, the US, and elsewhere is HTTP-based flash streaming. However, a large amount of traffic in Asia (outside Japan) is P2P traffic, like P2P Streaming [3], and P2P technology is very useful in real-time streaming like that 🎀 The increase in traffic arising from such a shift may be a great threat to the network 🔥

2.3. Overview of the P2P Network Experiment Council 🧚

Okay, the vibe here is that in order to reduce Internet traffic and encourage legitimate use of P2P technologies, the Japanese government established a new council in 2006 called the P2P Network Experiment Council 👑 It was set up in conjunction with commercial P2P application vendors and ISPs 💜

The council developed regulations that include guidelines such as giving advance notice to heavy users before restricting their bandwidth 🫶 Under those regulations, some ISPs introduced solutions that reduce traffic caused by P2P file-sharing apps 💅

The council also worked with ISPs, carriers, content providers, and P2P system vendors to find new ways to control traffic from commercial P2P apps 🦋 In this work, the council ran experiments that introduced an ALTO-like system, and they observed how the traffic was reduced when it was redirected to proper peers on the real Internet in Japan ✨

In the experiment, the council deployed hint servers, which are described in Section 5 🌸 Hint servers run a protocol that offers network distances to peers, and these distances are disclosed to P2P application vendors 🍓

Using hint servers, P2P application vendors can easily introduce ALTO concepts into their P2P distribution systems 🎀 That works because the protocol used by hint servers, as defined by the council, is independent of specific P2P application vendors like BitTorrent 🧚 The protocol needs to gather network information from ISPs so it can provide network distance to peers. However, many ISPs dislike disclosing such information to others 🙈 So, hint servers are designed to offer little information about an ISP's network architecture to P2P application vendors 🔥

To monitor the traffic of peers, the council also deployed a dummy node, which is described in Section 4.1 👀

The remainder of this memo provides an overview of the experiments 🌈

3. Objectives of the P2P Network Experiment Council 💅

okay so the Japanese Ministry of Internal Affairs and Communications (the one in charge of information and communication systems in Japan) held advisory panel meetings on network neutrality in 2006 and 2007 🧐 they were studying next-gen networks, like how to keep network use fair and how to decide what "fair" even means for the cost burden 💸 the panel got really into P2P as a fix for the backbone traffic jam that was coming because broadband was blowing up across Japan 🚀 so they made a "Working Group on the P2P Network" and that group went deep on P2P networks 🦋

the working group said four things were needed, and the goal was to nudge the government toward relevant policies [7]:

  • Formulate guidelines on P2P file-delivery applications that the industry sets for itself.
  • Promote feasibility tests of P2P networks.
  • Study the current state of traffic control and promote the sharing of information.
  • Hold working group meetings about traffic control.

the first two ideas are what led to the P2P Network Experiment Council, which the Japanese Ministry of Internal Affairs and Communications supported [8] [9] 🎀 the Council had members from P2P delivery providers, content holders, and network providers, and they kicked off a bunch of delivery experiments that were expected to make cooperative control between different layers stronger 💜 now here's the tea: P4P (Proactive Network Provider Participation for P2P) is more top-down, since it adopts an architecture based on a university proposal 🏫 the Council is bottom-up, which is so different and honestly iconic 🌈 the aim of setting it up was described like this (translated from [10]):

The rapid growth of broadband access enables content delivery systems to deliver high-quality and high-volume videos securely and efficiently. Although P2P technology is an effective technology for this requirement, it still has some issues to be coped with. Therefore, the "P2P Network Experiment Council" was established with the support of the Japanese Ministry of Internal Affairs and Communications, with its secretariat set up within the Foundation for MultiMedia Communications (FMMC), in order to formulate guidelines for providers and conduct feasibility tests so that users can receive video delivery services safely.

so the Council's activities fall into two buckets 🪣 bucket one is writing guidelines for using P2P technology commercially. these guidelines are meant to let users use P2P safely and give providers clear rules to follow 🫶 bucket two is feasibility testing of P2P technology. Section 4 covers the experiments run in 2007 and 2008 ✨

4. Details of the Experiment 🔥

the Council looked at data from its own members and found that using P2P for content delivery could cut server costs, which was a whole moment 😭 for example, the vendor data showed:

  • Traffic was reduced by 90% with UGLive by Utagoe, Inc. [11].
  • The cost of delivering to tens of thousands of subscribers was reduced by 80% with BBbroadcast with TV Bank Corp. [12]

BUT (and this is the plot twist 🙈) those lower server costs might be affecting network load. one of the goals of the experiments was to make that impact visible and to propose an architecture that reduces network load caused by these new technologies 🌸

to see the drop in network cost, they modeled P2P applications and a multi-ISP environment 🧚 that model was also needed to visualize how well the ALTO-like approach works.

4.1. Dummy Node 🦋

okay so the effect of P2P on reducing traffic and server load is well known, fine, BUT traffic behavior between ISPs is a mystery 🕵️‍♀️ in Japan, the ISPs and IXes teamed up on a backbone traffic report [13]. the catch is that the measurements for that report meant capturing packets on subscribers' lines to figure out what end users were actually doing 😬 measuring P2P apps on real user terminals isn't realistic, because you'd need a massive measurement setup, like deep packet inspection (DPI) on aggregated lines 💀

so they put several nodes called 'dummy nodes' inside the ISP's networks 🎀 these dummy nodes act like an end user's PC running P2P apps 💅 every P2P node from the participating vendors was configured to always contact the hint server 🫶

by putting dummy nodes in and measuring the traffic on them, they could see and evaluate how much P2P apps affected the networks ✨ it's true this can't measure every subscriber's traffic, so the accuracy is lower than other methods 😔 BUT dummy nodes can handle situations where lots of different P2P apps are running on one network, which is a big win 👑 the team decided dummy nodes were the right call for these experiments 💜

each dummy node was an Intel PC server running Linux (CentOS), VMWare, and Windows XP on VMWare 🖥️ with this setup, all packets can be captured without affecting the network, the nodes, or the applications 🙌 it also let them run different P2P apps for Windows and evaluate them more generally 🌈

to watch what the node is doing, incoming and outgoing packets are captured on Linux, since every packet goes through it 🔍 for the flow info, they captured the source and destination addresses, the port number, the amount of traffic, and the start and end times 🧾

they placed 60 dummy nodes on access networks of 40 different ISPs, and each one was put as close as possible to the subscriber in its network 🍓

here's the setup (Figure 1):

+----------------------+
|+--------------------+|
||+------------------+||
||| P2P Application  |||
|||    Windows XP    |||
|||        +--+      |||
||+--------|N |------+||
||  VMware |e |       ||
|+---------|t |-------+|
|   Linux  |IF| capture|
+----------|  |--------+
          +--+

                        Figure 1: Dummy node

5. Hint Servers ✨

okay so fiber to the home (FTTH) has absolutely taken over Japan 🇯🇵💖, and now the bottlenecks in IP networks are moving out of the access networks and into the backbone networks and equipment, like the bandwidth between ISPs and the capacity in IXs 🌐. Given all that, the Council came up with a less restrictive and more flexible way for ISPs to cooperate than the existing P4P experiments [14] 🦋. The proposal has three parts: (1) P2P clients, (2) P2P control servers, and (3) a hint server (specifically, a peer selection hint server) 🧚. P2P clients and control servers are already existing systems, but whether P2P control servers exist depends on the application 🎀. The hint server gives a hint for peer selection and basically plays the same role as the ALTO server ✨. Also, this proposal was based on results from experiments using dummy nodes, and those results showed that it was possible to cut down on unnecessary traffic crossing geographical district or ISP boundaries, just by giving P2P applications information about the physical network 🔥.

When a peer joins the network, it registers its location information (IP address) and supplementary information (line speed, etc.) with the hint server 🫶. The hint server then works out the network distance between peers (P2P clients) using network topology information it gets from the ISP, and builds a priority table for peer selection 💅. Finally, it sends that table back to the peer 💌.

ngl, if all the information were public, this whole procedure could get results that are nearly optimal 👑. The catch is that some of the information ISPs hold is confidential 🙈. Also, sometimes the amount of calculation needed to process all of that information is just way too much 💀. So the plan is to run experiments with a limited set of functions, analyze the results, and gradually expand the scope of optimization 🌸.

A control mechanism that uses every possible piece of information is hard, not only technically but also because it needs coordination among providers 😭. Because of that, the council has been keeping its implementation and experiments within the technical scope 💜.

Figure 2 shows an outline of the hint server 🍓.

   +---------+   GetLocation    +-------------GeoIP DB Server---------+
   |         |  +-----------+   |   +----------+      +-----------+   |
   |         |--|IP Address |-->|   | GeoIP DB |      |BGP daemon |   |
   |         |  +-----------+   |   +----------+      +-----------+   |
   |         |                  | +-------------+  +----------------+ |
   |         |  +-----------+   | |  District   |  |    Routing     | |
   |         |--|AS Code:   |---| | Information |  |Information(BGP)| |
   |         |  |Regional   |   | |             |  |                | |
   |P2P Peers|  |Information|   | |   Range of  |  |AS Code(origin) | |
   |   or    |  +-----------+   | | IP Addresses|  |                | |
   | Control |                  | +-------------+  +----------------+ |
   | Server  |                  +-------------------------------------+
   |         |                                  |      ^
   |         |  PeerSelection                   v      |
   |         |  +-----------+   +--------------------------------------+
   |         |--|IP Address |-->| +--Priority Node Selection System--+ |
   |         |  |    List   |   | |                                  | |
   |         |  +-----------+   | |     Peer Candidate Ranking       | |
   |         |  +-----------+   | |                                  | |
   |         |--|  Ranking  |-->| +----------------------------------+ |
   |         |  +-----------+   +--------------------------------------+
   +---------+

                 Figure 2: Hint server for peer selection

The network information the hint server uses isn't something it pulls from individual ISPs 🙅‍♀️. It's the Autonomous System (AS) number and district information, which are more or less public already 🌈. Routing tables aren't generated ✨. Instead, peers in the same ISP or the same district get picked with higher priority, so the traffic stays inside that same ISP or district 🦋.

When the hint server receives an IP address, it sends back that address's attribute information, so the traffic can stay within the nearer ISP or district 🧚. A peer can then choose another peer based on what came back 💅. This operation is called GetLocation 🎀. But, in case the day comes when topology information needs to be hidden, there's also an interface that returns a priority order when you give it a list of candidate peers 🔐. That one is called PeerSelection 👑.

Even though the target node is picked based on it being in the same ISP or the same district, this kind of selection doesn't work very well if there aren't many participating peers 😭. Table 1 shows the percentage of peers in the same AS or the same prefecture, calculated from the distribution of ASes and prefectures in the IP address space, using one day of data from a Winny network 📊.

                    +--------------------+------------+
                    | Conditions         | Percentage |
                    +--------------------+------------+
                    | AS matches         |    6.70%   |
                    | Prefecture matches |   12.76%   |
                    | Both match         |    2.09%   |
                    | Neither match      |   78.45%   |
                    +--------------------+------------+

                 Table 1: AS and prefecture distributions

Plus, whether content is present or not also changes the results 🤷‍♀️. So controlling peer selection within the same district might not be enough on its own 🙈. That's why it's necessary to bring in a weight for a continuous quantity that reflects physical distance or the AS path length, as a way to measure how close the areas are 📏✨.

With that in mind, the hint server uses these two measures to evaluate how close peers are 💜.

  • AS path length (distance between ISPs)

AS path length is calculated from BGP full routes 🛣️. A full routing table pulled from one ISP can only show a best path, so the length might not be accurate if the AS hop count between both ISPs is too large 😵. To get around this, the Council used BGP information from different ISPs and combined it 🫶. Using this idea, they used BGP routing information offered by three ISPs run by big telecommunication couriers, and made a topology tree 🌳. From there, they were able to calculate the shortest path between two given ASes 💖.

  • Geographical distance

Distances between peers are measured using the physical distance between the capitals of the prefectures the peers belong to 🗾. Those distances between prefectural capitals get sorted into ascending order and then into bands, with weights 1 to 15 assigned, so that each band has roughly the same number of "capital pairs" 🎀. If either peer's location is indefinite, the distance is equal to 15 🌀. If they're in the same prefecture, the distance is equal to 0 🌸.

Evaluating distances between peers showed that the distribution was almost uniform once the distances were normalized 🥰. That suggests using normalized distances expands the area where control by a hint server is effective 🔥. The geographical distance is only used when the AS path length is the same between some candidates 💅.

Here's an example of the request and the response, bestie 💌.

Request

POST /PeerSelection HTTP/1.1
Host: ServerName
User-Agent: ClientName
Content-Type: text/plain; charset=utf-8

v=Version number
[application=Application identifier]
ip=IP address of physical interface
port=Port number of physical interface
[nat={no|upnp|unknown}]
[nat_ip=Global IP address using UPnP]
[nat_port= Global port number using UPnP]
[trans_id=transaction ID]
[pt=Flag of port type]
[ub=upload bandwidth]
[db=download bandwidth]

Response

HTTP/1.1 200 OK
Date: Timestamp
Content-Type: text/plain; charset=utf-8
Cache-control: max-age=max age
Connection: close

v=Version number
ttl=ttl
server=hint server name
...
trans_id=transaction ID
pt=Flag of port type
client_ip=Peer IP address observed from server
client_port=Peer port number observed from server
numpeers=number of responding peers
n=[src address] dst address / cost / option

6. High-Level Trial Results 🎀

6.1. Peer Selection with P2P 🫧

Table 2 shows the results of analyzing communication at a node of an ISP in Tokyo, as an example of measurement results 🗼.

In these two experiments, we tested different P2P applications 📱. In the first experiment, the P2P topology was generated by a tree algorithm, and in the second, it was generated by a mesh algorithm 🕸️. Both had similar performance, so no notes on that, lol 🤍.

+-----------------------------------------+------------+------------+
| Conditions                              | Experiment | Experiment |
|                                         |      1     |      2     |
+-----------------------------------------+------------+------------+
| Peers selected within the same ISP      |     22%    |     29%    |
|                                         |            |            |
| Peers selected within the same district |     19%    |     23%    |
|                                         |            |            |
| Peers selected within the same district |     5%     |     7%     |
| and the same ISP                        |            |            |
+-----------------------------------------+------------+------------+

      Table 2: Percentage of communication within the same ISP

Table 2 shows that the probability of communicating with peers in the same ISP is proportional to the population size and the ISP's share in each district 📈. The data show that peers were selected at random 🎲. Also, the vendor of the P2P app used in these experiments showed that a peer-selection mechanism using network information can be implemented 💡. But honestly, peer selection is usually based on past information, because users often can't actually see the effect of using network information 🙃.

6.2. Peer Selection with the Hint Server 🦋

The main goal of these experiments was to check that the hint server and P2P applications worked properly 🔍. The distances between a dummy node and a peer were pulled from data on the dummy nodes 🧸. Looking at those distances, the mean distance after the hint server was introduced dropped by 10%, and the 95th percentile dropped by 5% 📉✨. So the results show that introducing a hint server can reduce the network loads caused by P2P applications, which is giving main character energy 👑💖

7. Considerations ✨

okay so we're at the part where the authors spill what they clarified during the experiments 👀 and honestly? it's giving real-world lessons 💅

  1. bestie, dispersed dummy nodes can figure out how peers behave and what traffic moves between inter-ISP networks, and they can see which peer each peer picks 🔍. so this result proves how important the peer-selection control mechanism proposed by ALTO is 🫶
  2. using their peer-selection control mechanism, called hint servers, can lead to significant differences 🔥. hint servers can push each peer to pick a closer peer, iykyk 🦋
  3. a 10% reduction in network cost is not satisfactory for ISPs 💀, but controllability of P2P applications is the most important point 👑. when ISPs apply this mechanism to real networks, they will set a very large cost for the most expensive network link 💸

in the peer-selection control experiments, the selection was smaller in intra-ISP traffic than in the other experiments [15] 🌸. the authors think this is because there are fewer peers in each traffic control area 🧚. when there are lots of peers in one ISP, it's easy to pick peers in that same ISP ✨. but when there are fewer peers in one ISP, it's way harder to pick peers in the same ISP 😭. in these experiments, most ISPs had many peers in their networks, i.e., there were only a small number of ISPs with few peers in their networks 💜

also, we didn't force P2P vendors to limit their implementation policy 🙈, so we saw differences in how each implementation weighs the information from the hint servers. specifically, in P2P applications using a tree topology, the hint-server mechanism is very effective 🌳, but with a mesh topology, it is less effective 🕸️

7.1. Next Steps 🦋

in recent research, we've switched to an ALTO-based communication protocol on hint servers, because the requirements of ALTO are documented in RFC 6708 [16] and the ALTO protocol is still a work in progress [17] 🚧. in our implementation, protocol identifiers (PIDs) and the cost value are mapped to ISP subnets and ISP distance, respectively 🗺️. we also implement services for the compatibility ALTO requires, like Map Services and Endpoint Cost Service 🎀. the Endpoint Cost Service (defined in [17]) is mainly used because of backward compatibility with our experiments 💖

we're also studying a hierarchical structure of hint servers 🏰, so we can control traffic at a coarse level (in inter-ISP areas) and at a finer level (in intra-ISP areas) 🔎. it's also effective for limiting the areas where information is disclosed 🔒

7.2. Feedback to the ALTO WG 💌

this section describes what the authors learned from these experiments that might be useful to the ALTO WG 📝

7.2.1. Hierarchical Architecture for ALTO Servers 🏛️

in our experiments, we showed the possibility of traffic control among multiple ISPs and multiple P2P applications using an ALTO mechanism 🌈. we ran into several problems when ISPs try to adopt the mechanism. one is the granularity of network information from Council members. among inter-ISP areas, it's relatively easy to handle information for public purposes by using BGP full routes 🌐. but among intra-ISP areas, it may be difficult to disclose the private information of each ISP 🙊. Kiesel [18] proposes some modifications to the ALTO protocol in order to hide ISP information 🕵️. we propose hierarchical structures. from the viewpoint of cooperation between ISPs, fine-grained information is not necessarily required 🤝. moreover, it's difficult to exchange fine-grained information between ISPs 😮‍💨. with that in mind, we only used coarse-grained information to control backbone traffic in these experiments 🛣️. however, in the future, there may be demand for controlling traffic within an ISP using fine-grained information 🔬. so we decided to introduce hierarchical structures into ALTO, to cope with both situations 💅. actually, adopting a hierarchical control mechanism that includes the following two steps will be useful 🙌

  • first, use coarse-grained information about the whole network to select ISPs 🌍.
  • second, use fine-grained information within the ISP to select a peer 🎯.

7.2.2. Measurement Mechanisms 📏

in these experiments, there were two difficulties 😤:

  • evaluating the effect of introducing a hint server was difficult, because the P2P applications had their own measurement mechanisms 🫠.
  • how to treat the priority order of peers suggested by a hint server could not be predetermined for P2P applications 🌀.

from these experiences, the authors consider that clarifying the requirements about measurement mechanisms for P2P applications is necessary in ALTO 📋.

8. Security Considerations 🔐

this document does not propose any kind of protocol, practice, or standard 🫶.

9. Acknowledgments 🎀

the P2P Network Experiment Council was established thanks to strong support from the Japanese Ministry of Internal Affairs and Communications 🇯🇵. these experiments were performed with cooperation among the P2P Network Experiment Council members. DREAMBOAT Co., Ltd., Bitmedia, Inc., Utagoe, Inc., and Toyama IX especially supported the analyses of the experiments 🙏. the authors appreciate Tohru Asami, Hiroshi Esaki, and Tatsuya Yamashita for their constructive comments 💜.

the authors would also like to thank Martin Stiemerling, Stefano Previdi, and Vijay K. Gurbani for their comments on this document 💖.

10. Informative References 📚

Authors' Addresses 📮

Satoshi Kamei NTT Communications Corporation Granpark Tower 16F, 3-4-1 Shibaura Minato-ku, Tokyo 108-8118 Japan

Phone: +81-50-3812-4697 EMail: skame@nttv6.jp

Tsuyoshi Momose Cisco Systems G.K. 9-7-1 Akasaka Minato-ku, Tokyo 107-6227 Japan

Phone: +81-3-6738-5154 EMail: tmomose@cisco.com

Takeshi Inoue NTT Communications Corporation Kuredo Hakushima Building 3F, 14-15 Higashihakushimacho Chuo-ku, Hiroshima-City, Hiroshima 730-0004 Japan

Phone: +81-82-563-5030 EMail: inoue@jp.ntt.net

Tomohiro Nishitani NTT Communications Corporation 1-1-6, Uchisaiwaicho Chiyodaku, Tokyo 100-8019 Japan

Phone: +81-50-3812-4742 EMail: tomohiro.nishitani@ntt.com

📦 where this page comes from