One document matched: draft-kamei-p2p-experiments-japan-09.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="no"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-kamei-p2p-experiments-japan-09" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="P2P Experiments Japan">
ALTO-Like Activities and Experiments in P2P Network Experiment Council
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Satoshi Kamei" initials="S.K." surname="Kamei">
<organization abbrev="NTT Communications">NTT Communications Corporation</organization>
<address>
<postal>
<street>Granpark Tower 17F, 3-4-1 Shibaura</street>
<city>Minato-ku</city>
<region>Tokyo</region>
<code>108-8118</code>
<country>JP</country>
</postal>
<phone>+81-50-3812-4697</phone>
<email>skame@nttv6.jp</email>
</address>
</author>
<author fullname="Tsuyoshi Momose" initials="T.M." surname="Momose">
<organization abbrev="Cisco Systems">Cisco Systems G.K.</organization>
<address>
<postal>
<street>9-7-1 Akasaka</street>
<city>Minato-ku</city>
<region>Tokyo</region>
<code>107-6227</code>
<country>JP</country>
</postal>
<phone>+81-3-6738-5154</phone>
<email>tmomose@cisco.com</email>
</address>
</author>
<author fullname="Takeshi Inoue" initials="T.I." surname="Inoue">
<organization>NTT Communications</organization>
<address>
<postal>
<street>3-4-1, Shibaura</street>
<city>Minato-ku</city>
<region>Tokyo</region>
<code>108-8118</code>
<country>JP</country>
</postal>
<phone>+81-3-6733-7177</phone>
<email>inoue@jp.ntt.net</email>
</address>
</author>
<author fullname="Tomohiro Nishitani" initials="T.N." surname="Nishitani">
<organization>NTT Communications</organization>
<address>
<postal>
<street>1-1-6, Uchisaiwaicho</street>
<city>Chiyodaku</city>
<region>Tokyo</region>
<code>100-8019</code>
<country>JP</country>
</postal>
<phone>+81-50-3812-4742</phone>
<email>tomohiro.nishitani@ntt.com</email>
</address>
</author>
<!--date month="October" year="2009" /-->
<date year="2012" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>IRTF</area>
<workgroup>P2PRG</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>overlay network, content delivery network, peer-to-peer, traffic engineering, experiments in Japan</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document introduces experiments to clarify how ALTO-like
approach was effective to reduce network traffic made by a
Council in Japan to harmonize P2P technology with the
infrastructure.
<!-- Specifically, describing Hint Server technology
similar to ALTO technology.-->
And this also provides some
suggestions that might be useful for ALTO architecture
learned through our experiments.
Especially, experiment for application independent ALTO-like
server operation.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
An overlay network, which is used by P2P and other applications, offers the advantage of allowing flexible provision of services while hiding the lower layer network.
The downside is that inefficient routes are often taken in the lower IP network, thereby increasing the network load.
Several proposals have been made to build an overlay network that takes account of the information about the lower layer network. <xref target="INFOCOMM2009"/> <xref target="IEEEJOURNAL2004" />
Since the management of the Internet is highly distributed, it is difficult to implement such proposals and thus optimize a network without the cooperation of network providers.
</t>
<t>
Recently, the controversy between the overlay network and the
network providers about network resource wastefulness has been rekindled.
Under these circumstances, some researchers have studied overlay network control technology that takes account of the network topology information obtained from network providers.
</t>
<t>
One of the activities concerning this issue has been made by the
P2P Network Experiment Council in Japan. We planned some
experiments in the council. This document reports
on the issues addressed and experiments being made by the
council.
</t>
<t>
This experiment made from 2007 to 2008, because P2P traffic had
reduced due to rivision of copyright law in Japan.
And recently, dominant traffic is HTTP based flash streaming in
Japan, U.S, and so on.
However, P2P traffic remains in large traffic, like
PPStreaming, in Asia (except Japan)<xref target="sandvine" />,
and P2P technology is very userful in such a realtime streaming area.
</t>
<t>
Our experience in this experiment might be useful for ALTO
architecture, especially for application independent and multi
application ALTO-like server operations. We suggest that
generic measurement mechanism is important because each
application has different mechanism and it is difficult to
compare the effectiveness.
</t>
<t>
This document is a product of the P2P 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.
</t>
</section>
<section title="Background in Japan">
<!--2.1-->
<section title="P2P traffic">
<t>
As of 2008, the world most popular P2P file sharing
application, Bittorrent, isn't widely deployed in Japan.
Instead, other Japan specific file sharing P2P applications
such
as <xref target="winny">Winny</xref>, <xref target="share">Share</xref>,
and so on, still occupy 40% of the Internet
traffic in Japan even though many those P2P users were
arrested for sharing illegal files with these P2P apps.
</t>
<t>
Each P2P file sharing application has a unique protocol and none of them have a large market share therefore making it hard to effectively control.
</t>
</section>
<!--2.2-->
<section title="Impact on network infrastructure">
<t>
One of the advantage of using P2P technology for content
delivery is that peers exchange content directly among
themselves without server bottleneck. This reduces the load on servers. Also, P2P
applications can reduce upstream traffic from an origin
content server. This reduce server cost dramatically.
<!--This is significant that the charge for
upstream traffic is usually delay-sensitive for content
delivery services, and it is not negligible.-->
</t>
<t>
<!-- Actually, the volume of traffic sent by the content server in -->
<!-- TVBank's P2P content delivery was reduced by a maximum of 96% -->
<!-- compared with the volume of traffic received by users <xref -->
<!-- target="3"></xref>. -->
It is also known that server cost could be reduced with P2P
technology. However, the story is quite different for
network providers.
From the viewpoint of network providers, the
traffic that content servers generate has shifted to the edge
network and the amount of traffic has not necessarily been
reduced with using P2P technology for reducing server cost.
Another problem for network providers that an
extremely inefficient routing may be selected has been
raised. It is because overlay network systems are configured
without any regard to the structure of the lower layer
network or network geometry.
</t>
<t>
In some cases, the total amount of traffic on the Internet used to be limited by the capacity of servers.
For those cases, P2P technology can improve the scalability of servers , however it may exhaust network resources.
Moreover, using P2P applications increases the volume of traffic per user remarkably.
</t>
<t>
Faced with increase in the load on network infrastructure,
network providers are compelled to take actions to overcome
the sudden increase in facilities' cost. Representative
actions include placing content in internet exchanges or data centers,
introducing bandwidth control, and raising the access
fees <xref target="mic" />.
</t>
<t>
However, current dominant traffic is HTTP based flash streaming in
Japan, U.S, and so on.
However, P2P traffic remains in large traffic, like
PPStreaming, in Asia (except Japan)<xref target="sandvine" />,
and P2P technology is very userful in such a realtime streaming area.
The
increase in traffic arising from such a shift may be a great
threat to the network.<!--
video posting sites, which has been delivered
using client-server applications, may adopt P2P system. The
increase in traffic arising from such a shift will be a great
threat to the network.
-->
</t>
</section>
<!-- 2.3 -->
<section title="The object of P2P Network Experiment Council">
<t>
In order to reduce Internet traffic and encourage legitimate
use of P2P technologies, the Japanese government led to
establish a new council called P2P Network Experiment Council
conjunction with commercial P2P application vendors and ISPs
in 2006.
</t>
<t>
Then the council had started to develop regulations that
include several guidelines such like an advance notice to
restrict bandwidth to heavy traffic users. In accordance with
the regulations, some ISPs introduced solutions that reduce
traffic caused by P2P file sharing applications.
</t>
<t>
Besides this activity, the council also looked for new ways
to control traffic by commercial P2P applications
with ISPs, carriers, contents providers and P2P system vendors.
In this work, the council had experiments that introduced
ALTO-like system and observed how the traffic was reduced by
redirecting to proper peers on the real Internet in Japan.
</t>
<t>
In our experiment, the council deployed hint servers, which are described in section 4.
Hint servers have a protocol offering network distance to peers, which is disclosed to P2P application vendors.
</t>
<t>
Using hint server, P2P application vendors can introduce ALTO concepts easily to their P2P distribution systems.
Because the protocol provided of hint servers is independent on specific P2P application vendors like Bittorrent, the council defines the protocol to be able to use any P2P application vendors.
It needs to gather network information from ISPs to offer network distance to peers, however many ISPs dislike to disclose such information to others.
Therefore, hint servers are designed to offer little information about ISPs' network architecture to P2P application vendors.
</t>
<t>
To monitor traffic of peers, the council also deployed dummy node, which are described in section 3.1.
</t>
<t>
This memo describes the overview of the experiments.
</t>
</section>
</section>
<!--
- This section is ommitted regard of Martin's comment. -
-->
<section title="The object of P2P Network Experiment Council">
<t>
Ministry of Internal Affairs and Communications Japan, which has jurisdiction over information and communication systems in Japan, held meetings of an advisory panel on network neutrality from 2006 to 2007 in order to study issues related to next generation networks, such as how to ensure fairness in the use of networks and how to define fairness in cost burden. The panel took an interest in P2P technology as a solution to the impending traffic saturation in the backbone network resulting from the rapid expansion of broadband access in Japan, and formed a "Working Group on the P2P Network", which carried out an intensive study of P2P networks.
</t>
<t>
The Working Group reported that it is necessary to undertake the following four activities, which are intended to encourage the government to adopt relevant policies <xref target="4"></xref>:
</t>
<t>
<list style="symbols">
<t>Formulate guidelines to be self-imposed by the industry on P2P file delivery applications,</t>
<t>Promote feasibility tests of P2P networks,</t>
<t>Study the current state of traffic control and promote the sharing of information,</t>
<t>Hold working group meetings on traffic control.</t>
</list></t>
<t>
The first two proposals led to the establishment of the P2P Network Experiment Council supported by Ministry of Internal Affairs and Communications Japan <xref target="5"></xref>.
The Council, with membership from P2P delivery providers, content holders, and network providers, began a variety of delivery experiments, which were expected to strengthen cooperative control between different layers. In contrast to P4P, which takes a relatively top-down approach of adopting architecture based on a proposal from a university, the Council is characterized by its bottom-up approach.
The aim of establishing the Council has been described as follows.
</t>
<t><list style="empty">
<t>
The rapid growth of broadband access enables content delivery system 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.
</t>
</list></t>
<t>
The activities of the P2P Network Experiment Council can be classified into two categories. The first is activities to formulate guidelines for the promotion of the commercial use of P2P technology. These will enable users to use P2P technology safely, and providers to have clear rules they must observe.
The other is feasibility tests of P2P technology. The next section describes mainly experiments conducted from 2007 to 2008.
</t>
</section>
<!-- -->
<section title="The details of the experiments">
<t>
The council has already learned that the server cost could be
reduced with using P2P technology for contents delivering by
investigating data offered by the members of the council. For
example, the data brought by the vendors shows as follows:
<list>
<t>
90% of traffic was reduced with UG Live by Utagoe Inc <xref
target="utagoe" />.
</t>
<t>
The costs of delivering to tens of thousand subscribers
was reduced to 1/5 with BBbroadcast with TV Bank
Corp. <xref target="3" />
</t>
</list>
</t>
<t>
On the other hand, these reduced server costs may affect
network load. One of the goals of our experiments was to
visualize the impacts and propose an architecture to reduce
network load caused by these new technologies.
</t>
<t>
In order to visualize the reduction of network cost, we had to
modelize P2P applications and multi-ISP environment. It will
also needed for visualizing the effectiveness of ALTO-like
approach.
<!--
be proposed should
be well generalized as possible that doesn't rely specific P2P
application behaviors because multi P2P application vendors
join these experiments. In addition, the traffic should be
captured beyond multi ISPs.
-->
</t>
<!--
<t>
参加しているP2Pアプリケーションベンダが複数あったことから，特定のP2Pアプリケーションに留まらず一般的に使える仕組を作ること．さらには複数のISPやバックボーン事業者が参加していることから，ISP間をまたがるトラヒックのふるまいを捉えることを重視した．
</t>
-->
<!--3.1-->
<section title="Dummy Node">
<t>
As mentioned before, while the effect of delivery using P2P technology on reducing the traffic and the load on servers is well known, traffic behavior in the inter-ISP is not known.
In Japan, there is a backbone traffic report cooperated with ISPs and IXes <xref target="impact_user_traffic" />.
However, this measurement requires to capture packets on subscribers line to know end user's activity.
<!--日本国内では大手ISPやIXの協力を得たトラヒック調査()があるが，このようなバックボーン回線での測定は網羅性はあるもののスケーラビリティに乏しい．-->
It is not realistic to measure the behavior of P2P applications at user terminals connected to the Internet because that would require a large-scale arrangement for measurement, such as using Deep Packet Inspection (DPI) on aggregated lines.
</t>
<t>
To solve these problems, we put several nodes called 'dummy nodes' in the ISP's networks.
The dummy nodes emulate an end user's PC and P2P applications are running on the nodes.
Every P2P node provided by participating vendors in the experiment was configured so it always contacted the hint server.
</t>
<t>
By introducing dummy nodes, we can observe and evaluate how
much P2P applications have affected networks by measuring the
traffic on dummy nodes. Since this method can't measure
every subscriber's traffic, the accuracy would be less than
other methods. But this make it possible to adapt to
situations many different P2P applications coexist on a
network. We can say this is suitable for these experiments.
<!--
これら dummy nodes は一般利用者を模擬した端末として多数をインターネットアクセス環境上に配置したうえでP2Pアプリケーションを起動し，それらノード間でのトラヒックを監視することでP2Pアプリケーションがネットワークに及ぼす影響を評価する．これらは全てのユーザを網羅できないのでサンプリングとしての測定にならざるを得ないが，一般的な挙動を調べるには充分であると考えた．また，多くのP2Pアプリケーションにおいて汎用的に適用できるという利点を持つ．
-->
</t>
<t>
A dummy node consists of Intel PC server, Linux(CentOS),
VMWare and Windows XP works on VMWare. With this configuration, all
packets can be captured without any impacts to the network, nodes and
application behaviors.
And it enable us to use different P2P applications for windows and evaluate them generally.
<!--
このような環境を用意することで，Windows対応の各種P2Pアプリケーションを起動し，，主要なP2Pアプリケーションを汎用的に評価可能である．
-->
</t>
<t>
To see behaviors of the node, incoming and outgoing packets are captured on Linux because every packets are transmitted through it.
In these experiments, we captured source/destination address, port number, amount of traffic and start/end time to see flow information.
<!--
ピア選択状況やISP間での転送量といったネットワーク上での挙動を把握するため，Linux上でパケットキャプチャを行う．取得する情報は，パケット送信元・送信先のアドレス・ポート，転送量，転送開始・終了時間といったフロー情報．
-->
</t>
<t>
60 Dummy nodes are put on access networks that are closest
subscriber as possible in different 40 ISP networks.
<!-- 以上のようなダミーノードを日本国内の実験に参加いただいたISP40社程度に60ノード配置した．配置箇所はユーザ環境にできるだけ近いところに置くようお願いをしている． -->
<!-- The nodes are actually placed on data centers, however, it wasn't matter because the bandwidth limited the subscribers line isn't measured in this experiment.
-->
</t>
<!--
このように構成したダミーノード群により，アプリケーションのコードそのものに手を加えることが難しい場合においても汎用的に評価するプラットフォームとして複数ISP間の状況を含むネットワーク上での挙動を測定できる．
-->
<figure anchor="dummy_node">
<artwork>
+----------------------+
|+--------------------+|
||+------------------+||
||| P2P Application |||
||| WindowsXP |||
||| +--+ |||
||+--------|N |------+||
|| VMware |e | ||
|+---------|t |-------+|
| Linux |IF| capture|
+----------| |--------+
+--+
</artwork>
<postamble>Dummy nodes</postamble>
</figure>
<!--
%Specifically, Linux servers were installed at 40 sites of some ISPs, and a virtual Windows environment was installed on the servers. P2P applications which were target to measure were running on th%at environment, and packets were captured by a Linux program to obtain information on communication destinations and communication frequencies.
-->
</section>
</section>
<!--4.2-->
<section title="Hint Server ('08)">
<t>
In Japan, bottleneck in IP networks have been shifting from access
networks to backbone networks and equipments, such as bandwidth
between ISPs and capacity in IXs, since FTTH has rapidly spread
all over Japan. Under these circumstances, the Council proposed a
less restrictive and more flexible cooperation between ISPs
than existent <xref target="p4p">P4P experiments</xref>.
The proposed method consists of the following elements: (1) P2P
clients, (2) P2P control servers, and (3) a hint server:
a peer selection hint server. (1) and (2) are existing systems but
whether (2) exists depends on each application. (3) is a server
that provides a hint as to the selection of a peer, and plays a
role equivalent to that of ALTO Server. Note that this
proposal was based on results of experiments using dummy
nodes. The results showed that it was possible to reduce
unnecessary traffic that flows across the boundaries of
geographical districts or ISPs through providing information
about the physical network to P2P applications.
</t>
<t>
<!--
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 makes a
mapping of the new peer (P2P client) based on network topology
information obtained from the ISP, generates a routing table in
which peers are listed in the order of priority for selection,
and returns the table to the peer.
-->
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 calculate network distance between peers (P2P client) based on network topology information obtained from the ISP and generates a priority table for peer selection.
The hint server returns the table to the peer.
</t>
<t>
If all information can be made publicly, the above procedure can
produce a result which is close to overall
optimization. However, some information held by ISPs can often
be confidential. Besides, in some cases, the volume of
calculation required to process all information can be
excessive. To avoid these problems, it is planned to conduct
experiments with a limited set of functions, analyze experiments
results, and gradually expand the scope of optimization.
</t>
<t>
A control mechanism that makes use of all possible information
is difficult not only technically but also difficulties to
achieve coordination among providers. In consideration of these
difficulties, the council has been
limiting the implementation and experiments to the following
scope since 2006.
</t>
<t>
<xref target="Figure 1 Peer selection hint server" /> shows an outline of the hint server.
</t>
<figure align="center" anchor="Figure 1 Peer selection hint server">
<!--<preamble>Figure 1 Peer selection hint server</preamble>-->
<artwork align="center">
<![CDATA[
+---------+ GetLocation +-------------GeoIP DB Server---------+
| | +-----------+ | +----------+ +-----------+ |
| |--|IP Address |-->| | GeoIP DB | |Quagga etc | |
| | +-----------+ | +----------+ +-----------+ |
| | | +-------------+ +----------------+ |
| | +-----------+ | | District | | Routing | |
| |--|AS Code: |---| | information | |information(DGP)| |
| | |Regional | | | | | | |
|P2P Peers| |Information| | | Range of | |AS Code(origin) | |
| or | +-----------+ | | IP address | | | |
| Contro| | | +-------------+ +----------------+ |
| Server | +-------------------------------------+
| | | ^
| | PeerSelection v |
| | +-----------+ +--------------------------------------+
| |--|IP Address |-->| +--Priority Node Selection System--+ |
| | | List | | | | |
| | +-----------+ | | Peer candidate ranking | |
| | +-----------+ | | | |
| |--| Ranking |-->| +----------------------------------+ |
| | +-----------+ +--------------------------------------+
+---------+
]]></artwork>
<postamble>Peer selection hint server</postamble>
</figure>
<t>
The network information used by the hint server is not
information solicited from individual ISPs but the AS number
and district information, which are more or less already
public. Routing tables are not generated. Instead, peers within
the same ISP or the same district are selected with higher
priority in order to confine traffic to within the same ISP or
the same district.
</t>
<t>
When the hint server receives an IP address, it returns its
attribute information, to achieve the above. A peer can select
a peer based on the returned information. This operation is
called GetLocation. However, in preparation for the time when
it becomes necessary to hide topology information, an interface
is provided through which a priority order is returned in
response to an input of a list of candidate peers. This
operation is called PeerSelection.
</t>
<t>
Although the target node is selected based on the criterion
that it is within the same ISP or the same district, this type
of selection is not very effective if the number of
participating peers is small. Table 1 shows ratio of peers
within the same AS or the same prefecture calculated from the
distribution of ASs and prefectures in the IP address space
from one-day data on a Winny network.
</t>
<texttable anchor="AS and prefecture distributions" title="AS and prefecture distributions">
<ttcol align="left">Conditions</ttcol>
<ttcol align="center">ratio</ttcol>
<c>AS matches</c>
<c>6.70%</c>
<c>Prefecture matches</c>
<c>12.76%</c>
<c>Both match</c>
<c>2.09%</c>
<c>Neither match</c>
<c>78.45%</c>
</texttable>
<t>
Since, in addition to the above, the presence/absence of
content affects the result, the control of selecting a peer
within the same district may be inadequate. Therefore, it is
necessary to introduce the weight of a continuous quantity that
reflects the physical distance or the AS path length as an
indicator of the proximity of the areas involved.
</t>
<t>
In consideration of the above, the following two measures are used for the evaluation of proximity between peers in a hint server.
</t>
<t><list style="symbols"><t>
AS path length (distance between ISPs)
</t></list></t>
<t><list style="empty"><t> AS path length calculated from BGP
full routes. Since a full routing table retrieved at an ISP
can show only a best path, it may not get an accurate length if
the AS hop of both ISPs is too large. To avoid this, we use
multiple BGP information received from different ISPs and combine
them. Based on this concept, we used BGP routing information's
offered by three ISPs operated by big telecommunication couriers
and made a topology tree. Then it enables to calculate the
shortest path between given two ASes.
<!--
まずはAS間の距離としてBGPのフルルートから得られるパス長(AS Hop)を用いる．特定ISPの情報のみを用いる場合にはベストパスだけしか取得できないため，特定ISPからAS Hopが大きいISP同士の距離が遠く誤判定されてしまう危険がある．そのため，本実験では複数のISPから得たBGP情報を合成することでこの問題を回避した．具体的には，日本国内最大手の通信会社系3ISPの経路情報を合成したトポロジツリーを作成し，このトポロジーツリーから最短路検索をすることで2AS間のホップ数を算出した．
-->
</t></list></t>
<t><list style="symbols"><t>
Geographical distance
</t></list></t>
<t><list style="empty"><t>
Distances between peers are measured using physical distance of prefectural capitals that target peers belong to. The distance between prefectural capitals is used to calculate physical distance. Distances between prefectural capitals are sorted into ascending order, and then into bands, with weights 1 to 15 assigned to them so that there are a more or less equal number of "capital pairs" in each band. If either of their location is indefinite, distance is equal to 15 and, if they are in the same prefecture, distance is equal to 0.
</t></list></t>
<t><list style="empty"><t>
Evaluation of distances between peers showed that the distribution of distances was almost uniform when distances between peers are normalized. This result suggests that using normalized distances expands the area where the control by a Hint Server is effective.
The geographical distance is only used when the AS path length
is same.
</t></list></t>
<t>An example of the request and the response</t>
<figure>
<preamble>o Request</preamble>
<artwork>
<![CDATA[
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=transcation ID]
[pt=Flag of port type]
[ub=upload bandwidth]
[db=download bandwidth]
]]>
</artwork>
<postamble></postamble>
</figure>
<figure>
<preamble>o Response</preamble>
<artwork>
<![CDATA[
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 respond peer
n=[src address] dst address / cost / option
]]>
</artwork>
</figure>
</section>
<section title="High-Level Trial Results">
<!--5.1-->
<section title="Peer Selection with P2P">
<t>
Table 2 shows the result of the analysis of communication in a node of an ISP installed in Tokyo, as an example of measurement results.
</t>
<t>
In these two experiments we evaluate different P2P applications, in
1st experiment, the P2P topology is generated by tree algorithm, and
in 2nd experiment, it is generated by mesh algorithm. Both of them
result in similar performance.
</t>
<texttable anchor="Percentage of communication within the same ISP" title="Percentage of communication within the same ISP">
<ttcol align="left">Conditions</ttcol>
<ttcol align="center">Experiment 1</ttcol>
<ttcol align="center">Experiment 2</ttcol>
<c>*Peers selected within the same ISP</c>
<c>22%</c>
<c>29%</c>
<c>*Peers selected within the same district</c>
<c>19%</c>
<c>23%</c>
<c>*Peers selected within the same district and the same ISP</c>
<c>5%</c>
<c>7%</c>
</texttable>
<t>
The table shows that the probability of communication with peers in the same ISP is proportional to the number of population and the share of the ISP in each district. The data show that peers were selected at random.
Note that the vendor of a P2P application used in these experiments explained that the mechanism of selection a peer using network information can be implemented. However, peer selection is normally based on past information because users often cannot actually perceive the effect of using network information.
</t>
</section>
<!--5.2-->
<section title="Peer Selection with the Hint Server">
<t>
<!--
Since the main objective of these experiments was to verify the operations of the hint server and P2P applications, the degree to which traffic in the network was actually reduced was not evaluated. However, the distances between a dummy node and a peer were obtained from data on the dummy nodes.
An examination of the distances between a dummy node and a peer revealed that mean value of distance after the hint server was introduced was reduced by 10% and that 95% value of that was reduced by 5%.
-->
The main objective of these experiments was to verify the operations of the hint server and P2P applications.
The distances between a dummy node and a peer were obtained from data on the dummy nodes.
An examination of the distances between a dummy node and a
peer revealed that mean value of distance after the hint
server was introduced was reduced by 10% and that 95th percentile was reduced by 5%.
The results show introducing hint server can reduce network loads by P2P applications.
</t>
</section>
</section>
<section title="Considerations">
<t>
We clarified followings throughout our experiments.
<!-- 以上の実験を通じて以下をあきらかにした．-->
<list style="numbers">
<t>
Dispersed dummy nodes can figure out the
behavior of peers and traffic between inter-ISP networks,
which peers are selected by each peer.
Therefore it proves that the importance of peer selection
control mechanism proposed in ALTO.
<!-- 1. 測定用ダミーノードを分散配置すること
によってネットワークをまたいだピア選択状況を把握することがで
きた．これにより近隣ピアの選択を制御する ALTO 型アプローチの
必要性が示せた．-->
</t>
<t>
Using our peer selection control mechanism, called hint
server, could achieve significant differences.
Our hint server can lead each peer to select nearer peer.
<!--
2. ヒントサーバを用いた制御においては，それぞれのピアの選択状況
においてISP間距離が小さいものを選択するという当初の目的は有為に
達成できた．
-->
</t>
<t>
The result of 10% reduction of network cost is not satisfying
effect for ISPs, but the controllability for P2P
applicationis most important point. When they apply this
mechanism for their real ISP network, they will set
very large cost for most expensive network link.
</t>
</list>
</t>
<t>
In the experimental result of peer selection control, it is
smaller in intra-ISP traffic than other experiments <xref target="comcast" />
<!-- 制御結果について，ISP単位での閉じ込め効果は既発表の実験結果と比 -->
<!-- べて小さくなっている． -->
We think that it is because there are smaller peers in each area
of traffic control.
When there are many peers in one ISP, it is easy to select
peers in the same ISP.
However, when there are small peers in one ISP, it is difficult
to select peers in the same ISP.
In the situation of our experiments, there are many ISPs of
peers belonging, and there are relatively smaller peers exist
in same ISP.
<!-- これはトラヒックを閉じ込める領域毎に所属するピアの絶対数が少ないことに起因している．つまり，特定のISPに所属するピア数が多い場合にはそのISP内のピアを選ぶことが容易であるのに比して，ピアが多数のISPに分散して分布する場合には同一ISPのピアを選択することがかならずしも可能ではない．このため，複数ISPによる協力の下実施した本実験においては，閉じ込め効果が少なく見えている． -->
</t>
<t>
Moreover, we didn't force P2P vendors to limit their
implementation policy, therefore we can observe differences
how each implementations weigh the information from the hint servers.
Especially, in tree overlay topology P2P applications,
such mechanism is very effective, on the other
hand, in mesh overlay system, less effective.
<!-- また，今回の実験においてはP2Pアプリケーションベンダに対して，実装上の制約を提示していない．このため，実装によってはヒントサーバから返ってくる情報をどの程度尊重しているかについて差が見られる．特にツリー型のP2Pアプリケーションにおいては効果が得られやすく，一方で対地が増えがちなメッシュ型のP2Pにおいては効果があらわれにくいという結果も得られた． -->
</t>
<section title="Next steps">
<t>
Recent research, we've changed the communication protocol to hint servers to ALTO based because it
is nearly standardized.
In our implementation, PIDs and the value of cost are mapped to ISP subnets, and ISP distance respectively.
We also implement services for compatibility required by ALTO such as Service Capability and Map Services.
But the Endpoint Cost Service is mainly used because of backward compatibility of our experiments.
<!-- 現在実施中の今年度実験においては，ALTOの仕様がほぼ固まってきていることを受け，ヒトサーバの仕様をALTO準拠にして実験を行っている．具体的には，ALTO Protocolのフォーマットに準拠し，Map ServiceにおけるPIDをISP毎のサブネットに対応させ，Costを前述のISP間距離とした．必須サービスの Service Capability，Map Service についても実装は行っているが，クライアント側で主に用いるインタフェースとしては昨年度以来との互換性を意識し，Endpoint Costサービスによる実装を中心としている． -->
</t>
<t>
We also study hierarchical hint server structure, in order to
control in coarse inter-ISPs and in detail intra-ISP.
<!-- また，昨年度来の実験においては複数ISPの連携による制御が実現できたことから，個別のISPにおけるより細かい制御を目的として，協力ISP毎にプライベートヒントサーバを設置，当該ISP内部においてはより細かい制御が可能となるような枠組を検討している． -->
It is also effective for limiting the area of information disclose.<!-- これは情報の開示範囲を制限するうえでも有用である． -->
</t>
<!--
This document has reported on activities aimed at achieving cooperative control between the P2P/overlay network and the network infrastructure. Specifically, it has described issues to be addressed and the activities of the P2P Network Experiment Council in Japan, which was established to address these issues. It has also introduced the Council's activities, from 2007 to 2008, focusing on the use of a Hint Server, which is a feature of the traffic engineering mechanism proposed by the Council.
The P2P Network Experiment Council has been renamed the Advanced Network Use Promotion Council. The new Council aims to create new network services suitable for the broadband environment and to promote the widespread use of such services in rural areas. It has expanded its scope of work to include all cache technologies, including P2P technology. It will promote more advanced use of the network by encouraging an exchange of views among a broad spectrum of parties on how to use the network effectively, and by supporting a variety of feasibility tests.
The Council aims to continue the analysis of the experiment results obtained, and further study by involving a wider spectrum of P2P providers, network providers and delivery service providers.
-->
</section>
<section title="Feedback to ALTO WG">
<t>
This section describes what the authors learned with these
experiments would be useful for the ALTO WG.
</t>
<!--7.1-->
<section title="Hierarchical architecture for ALTO servers">
<t>
In our experiments, we present the possibility of traffic
control among multi-ISPs and multi-P2P applications using ALTO mechanism.
<!-- 以上の実験を通して，ALTO の基本機能を用いることで複数ISP，複数P2Pアプリケーションにおいてもトラヒックの制御が可能であることがわかった． -->
On the other hand, we found several problems in ISP operations to adapt the mechanism.
One is the granularity of network information from council members.
Among inter-ISP area, it is relatively easy to treat
information for public purpose using BGP full route.
<!-- 実験を通じて実際にISPが導入していくにあたっての運用上の課題がいくつか明らかになった． -->
<!-- martin 氏の draft を引く
http://tools.ietf.org/html/draft-ietf-alto-deployments-00
ALTO Deployment Considerations draft-ietf-alto-deployments-00
-->
<!-- ひとつはネットワーク情報の粒度の問題である．全体としてうまく最適化を行うには今回の実験で行ったようにBGPフルルートを元にした情報で全体を動かすことができ，その場合には協力しているISPが全体的に利益を受けるために情報を出してもらいやすい． -->
<!-- その一方で，個別のISPでの制御は全体に見せる必要がないものや見せたくないものも含むため，連携に用いることが困難である． -->
On the other hand, among intra-ISP area, it may be
difficult to disclose private information of each ISP.
<xref target="I-D.kiesel-alto-h12" /> propose some modification for ALTO protocol
in order to hide ISP information.
<!--
ISPの情報を隠蔽する方法についての提案[]もあるが，
-->
We propose hierarchical structures.
From the viewpoint of cooperation between ISPs, fine-grained information is not necessarily required and moreover it is difficult to exchange the fine-grained information between ISPs.
Considering this situation, the authors use only
coarse-grained information to control backbone traffic in
this experiments, though demand of controlling traffic within an ISP using fine-grained information may arise in future.
Therefore it led us that introducing hierarchical structure into ALTO is necessary to cope with both situations.
Actually, to adapt a hierarchical
control mechanism which include the
following two steps will be useful.
</t>
<t>
<list style="symbols">
<t>
In the first step, coarse-grained information about whole the network is used to select ISPs.
</t>
</list>
</t>
<t>
<list style="symbols">
<t>
Next, fine-grained information within the ISP is used to select a peer.
</t>
</list>
</t>
<!-- We are using hierarchial approach with public and private -->
<!-- ALTO server for limiting information access. -->
<!-- パブリックなALTOサーバとプライベートなALTOサーバを分け
て階層化する解決策を今後の実験では取っていく予定である．
-->
</section>
<section title="Measurement mechanism">
<!-- <t> -->
<!-- もうひとつの課題は，導入効果の可視化が困難であるという点である．今回はダミーノードを使ってサンプル的に計測するという手法を取った．これはサーバやクライアント側に計測機構を設ける必要がないという点では汎用的であるが，配信毎に測定プラットフォームを維持し続ける必要があるため高コストである．今後はクラアントやALTOのサーバ側に計測機構を設けるような取り組みも必要だと考える．また，P2Pアプリケーション側がどの程度ALTOサーバの推薦に従ったかについても測定・検証できる枠組が実際にISPでの採用を促すにあたっては必要であろう． -->
<!-- </t> -->
<t>
In the experiments, there were two difficulties as follows:
</t>
<t>
<list style="symbols">
<t>
Evaluating effect of introducing a hint server was difficult, since P2P applications had their own measurement mechanisms.
</t>
</list>
</t>
<t>
<list style="symbols">
<t>
How to treat priority orders of peers suggested by a hint server could not be predetermined for P2P applications.
</t>
</list>
</t>
<t>
From these experiences, the authors consider that clarifying requirements about measurement mechanisms for P2P applications are necessary also in ALTO.
</t>
<!--
7.2
<section title="Measurement mechanism">
</section>
-->
</section>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not propose any kind of protocol, practice
or standard.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>No need to describe any request regarding number assignment.</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
Thanks to strong support by MIC (Ministry of Internal Affairs
and Communications of Japanese government), the council was established.
These experiments were performed under cooperation among P2P Network Experiment Council members, and DREAMBOAT co.,ltd., Bitmedia Inc., Utagoe. Inc. and Toyama IX have especially supported analyses of the experiments.
The authors appreciate Tohru Asami, Hiroshi Esaki and Tatsuya Yamshita for their constructive comments.
</t>
<t>
And the authors would like to thank Martin Stiemerling, Stefano Previdi and Vijay K.Gurbani for the comments on this document.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Informative References">
<reference anchor="INFOCOMM2009">
<front>
<title>On the Quality of Triangle Inequality Violation Aware Routing Overlay Architecture</title>
<author surname="R.Kawahara, E.K.Lua, M.Uchida, S.Kamei, H.Yoshino" fullname="Ryoichi Kawahara, Eng Keong Lua, Masato Uchida, Satoshi Kamei, Hideaki Yoshino" />
<date/>
</front>
<seriesInfo name="" value="INFOCOM 2009: 2761-2765" />
</reference>
<reference anchor="IEEEJOURNAL2004">
<front>
<title>QRON: QoS-aware routing in overlay networks</title>
<author surname="Z.Li" fullname="Zhi Li" />
<date year="JANUARY 2004" />
</front>
<seriesInfo name="" value="IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 22, NO. 1" />
</reference>
<reference anchor="winny" target="http://en.wikipedia.org/wiki/Winny">
<front>
<title>Winny on Wikipedia</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="share" target="http://en.wikipedia.org/wiki/Share_(P2P)">
<front>
<title>Share on Wikipedia</title>
<author/>
<date/>
</front>
</reference>
<!--
<reference anchor="1">
<front>
<title>The State of Traffic and the Effects of P2P</title>
<author>
<organization>Hiroshi Esaki</organization>
</author>
<date year="Special Symposium on Broadband, September 2008 (in Japanese)" />
</front>
</reference>
-->
<!--
<reference anchor="2">
<front>
<title>ISPs have Begun to Explore Tomorrow due to the Expansion of Traffic</title>
<author>
<organization>Yoichi Yamazaki</organization>
</author>
<date year="Nikkei Communications, December 2007 (in Japanese)" />
</front>
</reference>
-->
<reference anchor="3">
<front>
<title>Live Delivery using `BB Broadcast'Achieving 96% Saving in Traffic!</title>
<author>
<organization>TVBank</organization>
</author>
<date year="http:.wwww.tv-bank.com/jp/20081031.html, 2008 (in Japanese)" />
</front>
</reference>
<reference anchor="utagoe">
<front>
<title>UGLive technology introduction</title>
<author>
<organization>Utagoe Inc.</organization>
</author>
<date
year="http://www.utagoe.com/en/technology/grid/live/index.html, March, 2011" />
</front>
</reference>
<reference anchor="4">
<front>
<title>Disclosure of the Report `Working Group on P2P Networks'</title>
<author>
<organization>Ministry of Internal Affairs and Communications</organization>
</author>
<date year="http://www.soumu.go.jp/menu_news/s-news/2007/070629_11.html, 2007 (in Japanese)" />
</front>
</reference>
<reference anchor="5">
<front>
<title>The P2P Network Experiment Council</title>
<author>
<organization>The Foundation for MultiMedia Communications</organization>
</author>
<date year="http://www.fmmc.or.jp/P2P/about.htm, 2007 (in Japanese)" />
</front>
</reference>
<reference anchor="p4p">
<front>
<title>P4P Field Tests: Yale-Pando-Verizon</title>
<author>
<organization>Open P4P</organization>
</author>
<date year="http://www.openp4p.net/front/, 2009" />
</front>
</reference>
<reference anchor="comcast">
<front>
<title>RFC5632: Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial</title>
<author fullname="C. Griffiths, J. Livingood, L. Popkin,
R. Woundy, and Y. Yang">
<organization />
</author>
<date year="September 2009" />
</front>
</reference>
<reference anchor="mic" target="http://www.smartireland.jp/en/forum/may-2009/">
<front>
<title>Broadband Competition Policy in Japan</title>
<author surname="Taniwaki" fullname="Yasu Taniwaki">
<organization>Ministry of Internal Affairs and Communications</organization>
</author>
<date year="2008" />
</front>
</reference>
<reference anchor="impact_user_traffic">
<front>
<title>The Impact and Implications of the Growth in Residential User-to-User Traffic</title>
<author surname="Cho" fullname="Kenjiro Cho"></author>
<author surname="Fukuda" fullname="Kensuke Fukuda"></author>
<author surname="Esaki" fullname="Hiroshi Esaki"></author>
<author surname="Kato" fullname="Akira Kato"></author>
<date month="September" year="2006" />
</front>
<seriesInfo name="" value="SIGCOMM2006, pp207-218, Pisa, Italy" />
</reference>
<reference anchor="sandvine" target="http://www.sandvine.com/news/global_broadband_trends.asp">
<front>
<title>Global Internet Phenomena Report: 1H 2012</title>
<author surname="Sandvine Corp"></author>
<date month="September" year="2012" />
</front>
</reference>
<reference anchor="I-D.kiesel-alto-h12">
<front>
<title>ALTO H12,draft-kiesel-alto-h12-02 (work in progress)</title>
<author fullname="Kiesel, S. and M. Stiemerling">
<organization />
</author>
<date year="March 2010" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:17:35 |