P2PRG                                                           S. Kamei
Internet-Draft                                           NTT Corporation
Intended status: Informational                                 T. Momose
Expires: May 24, 2011                                      Cisco Systems
                                                                T. Inoue
                                                            T. Nishitani
                                                      NTT Communications
                                                       November 20, 2010


 ALTO-Like Activities and Experiments in P2P Network Experiment Council
                  draft-kamei-p2p-experiments-japan-04

Abstract

   This document provides some suggestions about ALTO architecture
   through experiments made by P2P Network Experiment Council in Japan.
   This document also introduces experiments made by the Council in
   Japan to harmonize P2P technology with the infrastructure.
   Specifically, this document describes Hint Server technology, which
   is similar to ALTO technology.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 24, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the



Kamei, et al.             Expires May 24, 2011                  [Page 1]


Internet-Draft            P2P Experiments Japan            November 2010


   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) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Background in Japan  . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  P2P traffic  . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Impact on network infrastructure . . . . . . . . . . . . .  4
   3.  Activity in P2P Network Experiment Council . . . . . . . . . .  5
     3.1.  Dummy Node . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Hint Server ('08)  . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Difference between P4P and Hint Server technology  . . . .  9
     3.4.  Difference between ALTO and Hint Server technology . . . . 11
   4.  High-Level Trial Results . . . . . . . . . . . . . . . . . . . 11
     4.1.  Peer Selection with P2P  . . . . . . . . . . . . . . . . . 11
     4.2.  Peer Selection with the Hint Server  . . . . . . . . . . . 12
   5.  Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Feedback to ALTO WG  . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Harmonizing a Hint Server with ALTO  . . . . . . . . . . . 13
     6.2.  Measurement mechanism  . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   10. Informative References . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15















Kamei, et al.             Expires May 24, 2011                  [Page 2]


Internet-Draft            P2P Experiments Japan            November 2010


1.  Introduction

   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.  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.

   Recently, the controversy between the overlay network and the network
   providers have 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.

   One of activities concerning this issue has been made by the P2P
   Network Experiment Council in Japan.  This document reports on the
   issues addressed and experiments being made by the P2P Network
   Experiment Council in Japan, focusing on the experiments made from
   2007 to 2008.


2.  Background in Japan

2.1.  P2P traffic

   In Japan, the major of P2P applications used today is Winny [1].  P2P
   applications are the sources of a considerable volume of traffic.
   Recent study [2] showed more than 60% of Internet traffic in Japan is
   generated by P2P applications.

   Although traffic from P2P applications increased much more rapidly
   than traffic from client-server-type web applications, it has leveled
   off lately as a result of legal restrictions advocated by copyright
   management organizations and traffic control implemented by ISPs.
   According to [3], video delivery sites using Flash has again
   increased volume of web traffic per user, making P2P traffic
   relatively less conspicuous than before.

   Consequently, some believe that P2P traffic is no longer a threat to
   the infrastructure.  P2P applications, however, rapidly became widely
   used to get around the limit of the servers' capacity, which was
   caused by the increase in demand for delivery of music files.  As of
   2007, it was likely that the traffic of client-server video delivery
   would shift to P2P delivery.



Kamei, et al.             Expires May 24, 2011                  [Page 3]


Internet-Draft            P2P Experiments Japan            November 2010


   In fact, some P2P content delivery systems solve copyright issues,
   for example, Sharecast, Ocean-Grid, TVBand, and so on.  The
   transmission of President Obama's Inaugural Address, which is the
   largest-scale transmission of content in recent history, was mostly
   of the client-server type.  However, the delivery by CNN used a P2P
   plug-in made by Octoshape.

2.2.  Impact on network infrastructure

   One of advantage of using P2P technology for content delivery is that
   peers exchange content directly among themselves.  This reduces the
   load on servers.  Also, P2P applications can reduce upstream traffic
   from an original content server.  This is significant that the charge
   for upstream traffic is usually traffic-sensitive for content
   delivery services, and it is not negligible.

   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 [4].  This
   indicates the great cost-saving of P2P technology from the
   perspectives of the load on server hardware and the traffic relaying
   cost of data centers.  However, the story is quite different for
   network providers.  From 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.  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.

   In some cases, traffic on the Internet used to be limited by the
   capacity of servers.  For those cases, the improvement in the
   scalability of servers has made it likely that network resources will
   be used up before server resources are.  Using P2P applications
   increases the volume of traffic per user remarkably.

   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 IXs or data centers, introducing bandwidth control, and
   raising the access fees [2].

   In the future, 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.





Kamei, et al.             Expires May 24, 2011                  [Page 4]


Internet-Draft            P2P Experiments Japan            November 2010


3.  Activity in P2P Network Experiment Council

3.1.  Dummy Node

   While the effect of delivery using P2P technology on reducing the
   traffic and the load on servers is well known, traffic behavior in
   the Internet is not known.  However, 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.  To solve this problem, dummy nodes which act like consumers
   node have been introduced.  Dummy nodes have been settled in the
   Internet and P2P applications have been installed on these nodes.
   Dummy nodes enable us to measure and analyze communication among
   peers.

   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 that
   environment, and packets were captured by a Linux program to obtain
   information on communication destinations and communication
   frequencies.  The nodes are placed on data centers, however, it
   wasn't matter because the bandwidth limited the subscribers line
   isn't mesured in this experiment.

3.2.  Hint Server ('08)

   In Japan, bottleneck in IP networks will shift 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 this situation. the Council proposed a less restrictive and
   more flexible cooperation between ISPs than ALTO.  The proposed
   method consists of the following elements: (1) P2P clients, (2) P2P
   control servers, and (3) a peer selection hint server, and a 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
   iTracker in P4P's study.  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 districts or ISPs through providing information about
   the physical network to P2P applications.

   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



Kamei, et al.             Expires May 24, 2011                  [Page 5]


Internet-Draft            P2P Experiments Japan            November 2010


   of priority for selection, and returns the table to the peer.

   If all information can be made public, 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
   experiment results, and gradually expand the scope of optimization.

   A control mechanism that makes use of all possible information is
   difficult not only technically but also because it is difficult to
   achieve coordination among providers.  In consideration of these
   difficulties, the P2P Network Experiment Council has been limiting
   the implementation and experiments to the following scope since 2006.

   Figure 1 shows an outline of the hint server.


   +---------+   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 |-->| +--Prioryty Node Selection System--+ |
   |         |  |    List   |   | |                                  | |
   |         |  +-----------+   | |     Peer candidate ranking       | |
   |         |  +-----------+   | |                                  | |
   |         |--|  Ranking  |-->| +----------------------------------+ |
   |         |  +-----------+   +--------------------------------------+
   +---------+

                                 Figure 1

   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



Kamei, et al.             Expires May 24, 2011                  [Page 6]


Internet-Draft            P2P Experiments Japan            November 2010


   district are selected with higher priority in order to confine
   traffic to within the same ISP or the same district.

   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.

   Although the priority 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.

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

                 Table 1: AS and prefecture distributions

   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.

   In consideration of the above, the following two measures are used
   for the evaluation of proximity between peers in a Hint Server.

   o  AS path length (distance between ISPs)

      Distances between peers are weighted using the degree of paths'
      matching from an origin AS to ASs that target peers belong to.
      The degree of paths' matching means ratio of common paths from an
      origin AS (for example, 4/6 between A-B-C, and A-B-D, 6/8 between
      A-B-C-D and A-B-C-E).  In this year, the OCN is used as an origin
      AS.  Distance is calculated as int((1.0- degree of matching of AS
      paths)*15).  Distance is 15 if either of AS path is indefinite,



Kamei, et al.             Expires May 24, 2011                  [Page 7]


Internet-Draft            P2P Experiments Japan            November 2010


      and is 0 if there is a perfect match.

   o  Physical distance

      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.

      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.

   An example of the request and the response

   o 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=transcation ID]
       [pt=Flag of port type]
       [ub=upload bandwidth]
       [db=download bandwidth]











Kamei, et al.             Expires May 24, 2011                  [Page 8]


Internet-Draft            P2P Experiments Japan            November 2010


   o 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 respond peer
      n=[src address] dst address / cost / option

3.3.  Difference between P4P and Hint Server technology

   To explain difference between P4P and Hint Server technology, the
   architecture proposed by P4P is described.  P4P aims to control
   traffic in such a way that traffic is confined within the same
   district or AS.  As shown in Figure 2, iTracker provides an interface
   for P2P content delivery using appTracker and peers in BitTorrent.
   This arrangement provides a framework for efficient control based on
   network information.

   In this framework, it is proposed that ISPs and applications share
   the following types of information through iTracker:

   o  Info: information about peers within an ISP

      - ASID AS number

      - Group number of PID node (peer)

      - LOC: virtual and geographical coordinates

   o  Policy: information about policy on usage specified by an ISP

      - Ratio between outgoing traffic and incoming traffic that flows
      between domains






Kamei, et al.             Expires May 24, 2011                  [Page 9]


Internet-Draft            P2P Experiments Japan            November 2010


      - Desirable daily traffic variation pattern on a link

      - Specifications about relations between peer groups (PID)

   o  Capability: information about the capability of an ISP

      - Information about usable service classes

      - Information about the cache server

   Note that [5] reports on the results of a field test in which it was
   attempted to reduce overall traffic by using the above concept to
   confine traffic exchange destinations to within the same ISP or the
   same city.  It reports that, in an evaluation with a Verizon network,
   traffic to locations outside an ISP was reduced by 30 to 50% and that
   the ratio of inter-city traffic to Verizon's total traffic was more
   or less halved.


                            ISP
                +------------------------+         Internet
                |   +----------------+   |      +------------+
                |   |  iTracker      |   |      | appTracker |
                |   |   *Info        |--------> +------------+
                |   |   *Policy      |   |            ^
                |   |   *capability  |   |            |
                |   +----------------+   |            |
                |                        |            |
                |   +----------------+   |            |
                |   |      Peer      |----------------+
                |   +----------------+   |
                +------------------------+

                                 Figure 2

   Comparing P4P with Hint Server technology, the following three
   differences are observed:

   o  Target of optimization:

      P4P technology focuses on optimization within an ISP, while Hint
      Server technology focuses on optimization in backbone traffic.

   o  Target applications:

      P4P technology focuses on supporting BitTorrent, while Hint Server
      technology does not specify any P2P applications.




Kamei, et al.             Expires May 24, 2011                 [Page 10]


Internet-Draft            P2P Experiments Japan            November 2010


   o  Strength of cooperation between P2P providers and ISPs:

      P4P technology requires close cooperation between ISPs and P2P
      providers, while Hint Server technology does not require.

3.4.  Difference between ALTO and Hint Server technology

   ALTO technology is more general approach than P4P technology.  And
   Hint Server technology has more similar focus of this technology.

   Hint Server offers similar information of ALTO service and can easily
   supports following ALTO Services.

   o  Map Service

      The cost type is computed by physical distance and AS path length,
      and the mode is numerical.

      PID information, it is same as AS and physical location, does not
      offered to client.

   o  Map Filtering Service

   o  Endpoint Cost Service

      Hint Server only offers map information associated with requested
      IP addresses.

   ALTO framework has more generality but the following two points are
   not sufficiently improved or some operational solution should be
   offered.


4.  High-Level Trial Results

4.1.  Peer Selection with P2P

   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.

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




Kamei, et al.             Expires May 24, 2011                 [Page 11]


Internet-Draft            P2P Experiments Japan            November 2010


   | *Peers selected within the same         |     5%     |     7%     |
   | district and the same ISP               |            |            |
   +-----------------------------------------+------------+------------+

         Table 2: Percentage of communication within the same ISP

   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 this experiment 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.

4.2.  Peer Selection with the Hint Server

   Since the main objective of this experiment 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%.


5.  Next steps

   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.




Kamei, et al.             Expires May 24, 2011                 [Page 12]


Internet-Draft            P2P Experiments Japan            November 2010


   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.


6.  Feedback to ALTO WG

   This section describes what the authors learned with this experiment
   would be useful for the ALTO WG.

6.1.  Harmonizing a Hint Server with ALTO

   As described before, a Hint Server control mechanism focuses on
   control between ISPs, while ALTO does control within an ISP.
   Generally speaking, control mechanism that a peer chooses a replica
   from its neighbors shows higher performance when probability of a
   peer having a content is higher.  This means ISP cooperation
   mechanism that enlarges area in choosing peers will have much impact
   on P2P performance.  The authors consider combination of these two
   mechanisms produce better P2P performance.  The authors propose
   hierarchical structure to harmonize a Hint Server with ALTO.  From
   viewpoint of cooperation between ISPs, fine information is not
   necessarily required and it is difficult to exchange fine information
   between ISPs.  Considering this situation, the authors use only
   coarse information to control backbone traffic in the experiments
   this year, though demand of controlling traffic within an ISP using
   fine information will arise in the near future.  The authors consider
   that introducing hierarchical structure into ALTO is necessary to
   cope with both situations.  Actually, the authors plan to try a
   hierarchical control mechanism in the next steps, which include the
   following two steps.

   o  In the first step, coarse information about whole the network is
      used to select ISPs.

   o  Next, fine information within the ISP is used to select a peer.

6.2.  Measurement mechanism

   In experiments, there were two difficulties as follows:

   o  Evaluating effect of introducing a Hint Server was difficult,
      since P2P applications had their own measurement mechanisms.

   o  How to treat priority orders of peers suggested by a Hint Server
      could not be predetermined for P2P applications.

   From these experiences, the authors consider that clarifying



Kamei, et al.             Expires May 24, 2011                 [Page 13]


Internet-Draft            P2P Experiments Japan            November 2010


   requirements about measurement mechanisms for P2P applications are
   necessary also in Alto.


7.  Security Considerations

   There are no security considerations in this document.


8.  IANA Considerations

   No need to describe any request regarding number assignment.


9.  Acknowledgments

   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
   experimernts.  The authors appreciate Tohru Asami, Hiroshi Esaki and
   Tatsuya Yamshita for their constructive comments.


10.  Informative References

   [1]  "Winny on Wikipedia", <http://en.wikipedia.org/wiki/Winny>.

   [2]  Hiroshi Esaki, "The State of Traffic and the Effects of P2P",
        Special Symposium on Broadband, September 2008 (in Japanese).

   [3]  Yoichi Yamazaki, "ISPs have Begun to Explore Tomorrow due to the
        Expansion of Traffic", Nikkei Communications, December 2007 (in
        Japanese).

   [4]  TVBank, "Live Delivery using `BB Broadcast'Achieving 96% Saving
        in Traffic!", http:.wwww.tv-bank.com/jp/20081031.html, 2008 (in
        Japanese).

   [5]  Open P4P, "P4P Field Tests: Yale-Pando-Verizon",
        http://www.openp4p.net/front/fieldests, 2009.

   [6]  Ministry of Internal Affairs and Communications, "Disclosure of
        the Report `Working Group on P2P Networks'",
        http://www.soumu.go.jp/menu_news/s-news/2007/070629_11.html,
        2007 (in Japanese).

   [7]  The Foundation for MultiMedia Communications, "The P2P Network
        Experiment Council", http://www.fmmc.or.jp/P2P/about.htm, 2007



Kamei, et al.             Expires May 24, 2011                 [Page 14]


Internet-Draft            P2P Experiments Japan            November 2010


        (in Japanese).


Authors' Addresses

   Satoshi Kamei
   NTT Service Integration Laboratories
   3-9-11, Midori-cho
   Musashino-shi, Tokyo  180-8585
   JP

   Phone: +81-422-59-6942
   Email: kamei.satoshi@lab.ntt.co.jp


   Tsuyoshi Momose
   Cisco Systems G.K.
   2-1-1 Nishi-Shinjuku
   Shinjuku-ku, Tokyo  163-0409
   JP

   Phone: +81-3-5324-4154
   Email: tmomose@cisco.com


   Takeshi Inoue
   NTT Communications
   3-4-1, Shibaura
   Minato-ku, Tokyo  108-8118
   JP

   Phone: +81-3-6733-7177
   Email: inoue@jp.ntt.net


   Tomohiro Nishitani
   NTT Communications
   1-2-20, Shibaura
   Minato-ku, Tokyo  108-8118
   JP

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








Kamei, et al.             Expires May 24, 2011                 [Page 15]