PPSP                                                             Y.Zhang
Internet Draft                                              China Mobile
Intended status: Standard Track                                   N.Zong
                                                .                 J.Seng
                                                         Yale University

Expires: November 2009                                      May 27, 2009

             Problem Statement of P2P Streaming Protocol (PPSP)

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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 27, 2009.

Copyright Notice

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

Zhang                 Expires November 27, 2009               [Page 1]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

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


   We propose to develop an open peer-to-peer (P2P) streaming protocol
   named PPSP. This document describes problem related to PPSP and
   outlines considerations that have to be taken in account when
   arriving at equitable solutions.

Zhang                 Expires November 27, 2009               [Page 2]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

Table of Contents

Zhang                 Expires November 27, 2009               [Page 3]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

1. Introduction

   Streaming traffic is among the fastest growing traffic on the
   Internet. In a recent white paper, Cisco predicts that by 2012, 90%
   of all Internet traffic will be video [Cisco].

   There are two basic architectures for delivering streaming traffic on
   the global Internet: the client-server paradigm and the peer to peer
   (P2P) paradigm [P2PStreamingSurvey]. A particular advantage of the
   P2P paradigm over the client-server paradigm is its scalability. As
   an example, PPLive [PPLive], one of the largest P2P streaming vendors,
   is able to distribute large-scale, live streaming programs such as
   the CCTV Spring Festival Gala to more than 2 million users with only
   a handful of servers. CNN[CNN] reported that P2P streaming by
   Octoshape played a major role in its distribution of the historical
   inauguration address of President Obama.  It is well demonstrated in
   practice that P2P streaming can deliver videos encoded at a rate of
   about 400 Kbps, in the presence of rapid user joins/leaves, with
   positive user experiences.

   With the preceding technical advantages, P2P streaming is seeing
   rapid deployment. Large P2P streaming applications such as PPLive
   [PPLive], PPstream [PPstream] and UUSee [UUSee] each has a user base
   exceeding 100 millions. P2P streaming traffic is becoming a major
   type of Internet traffic in some Internet networks. For example,
   according to the statistics of a major Chinese ISP, the traffic
   generated by P2P streaming applications exceeded 50% of the total
   backbone traffic during peak time in 2008. There were reports that
   major video distributors such as Youtube [youtube] and tudou [tudou]
   are conducting trials of using P2P streaming as a component of their
   delivery infrastructures.

   Given the increasing integration of P2P streaming into the global
   content delivery infrastructure, the lacking of an open, standard P2P
   streaming protocol becomes a major missing component in the Internet
   protocol stack. Multiple, similar but proprietary P2P streaming
   protocols result in repetitious development efforts and lock-in
   effects. More importantly, it leads to substantial difficulties when
   integrating P2P streaming as an integral component of a global
   content delivery infrastructure. For example, proprietary P2P
   streaming protocols do not integrate well with existing cache and
   other edge infrastructures.

1.1. Research or Engineering

   As [P2PStreamSurvey] identifies, there exist multiple proprietary P2P
   streaming systems including PPLive, PPstream, UUsee, Pando, abacast,

Zhang                 Expires November 27, 2009               [Page 4]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

   and Coolstreaming. A natural question to ask is whether the
   development of P2P streaming is mature and ready for standardization.
   We admit that P2P streaming will continue to improve and evolve.
   However, our investigation shows that existing P2P streaming systems
   are largely converging, sharing similar architecture and signaling
   protocols [draft-zhang-ppsp-protocol-comparison-measurement-00]. The
   competition of P2P streaming vendors become increasingly on contents.

1.2. Objective and outline

   Our objective is to develop a standard P2P streaming protocol that
   can operate in both fixed and mobile Internet. The protocol will
   serve as an enabling technology, building on the development
   experiences of existing P2P streaming protocols. It will integrate
   with IETF efforts on distributed resource location, traffic
   localization, and streaming control mechanisms. It allows effective
   integration with edge infrastructures such as cache and mobile edge

   This document provides a problem statement for designing PPSP. The
   rest of the document is organized as follows. In Section 2, we
   introduce terminologies. In Section 3, we identify key use cases
   where a standard P2P streaming protocol can facilitate the
   integration of P2P streaming into the network infrastructure, and
   therefore benefit both the content distributors and the networks. In
   Section 4, we describe the main issues to consider when designing
   PPSP. In Section 5, we outline the main scope of work.

Zhang                 Expires November 27, 2009               [Page 5]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

2. Definitions

   The following terms have special meaning in the definition of thePeer
   to Peer Streaming Protocol (PPSP) problem.

   Tracker: A dedicated server who is in charge of maintaining peer list
   and replying peer request for peer selection.

   Peer: A peer refers to a participant in a P2P streaming system who
   acts both as ''client'' and ''server''.

   Chunk: A chunk is a basic unit of partitioned streaming, which is
   used for the purpose of storage and advertising to neighbors what
   parts of a movie a peer holds [Sigcomm:P2P streaming].

   Bitmap: Bitmap is a table indicating which chunks a peer has.

   Peering networks: Two directly connected Internet Service Providers.
   Apart from infrastructure and operational costs, peering traffic is
   usually free, within the contract of a peering a greement [draft-

3. Problem Statement Scope

   We perceive a number of problems related to scalable and economical
   streaming on the Internet. The major issues are the following:

      1) The difficulty of an open PPSP due to the existence of many
      proprietary and non-interoperable protocols in current p2p
      streaming applications;

      2) The difficulty of integrating current edge equipments such as
      cache and content distribution network (CDN) nodes into P2P

      3) The difficulty of integrating related protocols into P2P streaming,
      like RELOAD,ALTO,RTSP, which is beyond current P2P streaming usage;

      4) The lack of a standard solution for scalable and economical
      streaming signaling interaction suitable both for fixed internet
      and mobile Internet; a related problem is that the difficulty of
      deploying p2p streaming in mobile Internet;

    The subsections below discuss these problems in more detail.

Zhang                 Expires November 27, 2009               [Page 6]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

3.1. Proprietary protocols and an open PPSP

   Currently there exist some P2P streaming systems like PPLive,
   PPstream, UUsee, Pando[Pando] and
   Coolstreaming[Coolstreaming].Although using similar system
   architecture as well as signaling interaction processes[draft-zhang-
   ppsp-protocol-comparison-measurement-00], due to their proprietary
   protocols, it's hard to develop an open PPSP protocol without
   checking all the typical P2P streaming systems, identifying the key
   issues and considering all the requirements.

3.2. Integrating cache and CDN into P2P streaming

   To make P2P streaming stable and traffic local enough, cache and
   other edge infrastructure is a very promising means [draft-marocco-

   However there are a few obstacles in deploying P2P caches [HTPT]:
   firstly, P2P caching systems are likely to be very complicated.
   Unlike web traffic standardized in using HTTP transport through few
   dedicated ports like 80, there is no a standard P2P protocol and
   every P2P protocol uses its own port. Therefore, P2P caching systems
   are forced to take an ad hoc approach by enumerating and handling
   every P2P protocol. Another drawback of this ad hoc approach is the
   requirement of regular update of the P2P cache engines to handle
   newly emerged popular P2P protocols. Secondly, extra, possibly huge,
   investment is required for the equipment and facility purchase and
   also the administrative cost.

   If we can utilize the existing cache and other edge equipments like
   CDN nodes, the cost can be heavily reduced. Meanwhile because it's
   widely used, the performance of P2P streaming can increase much.
   Therefore how to utilize the edge infrastructure is a big issue.
   Current web cache or other widely deployed edge equipments like CDN
   doesn't support P2P streaming yet[HTPT].

3.3. Integrating existing protocols into P2P streaming

   There are several protocols related to p2p streaming having been or
   being defined in IETF, including RELAOD,ALTO,RTSP,etc.., where
   P2PSIP,ALTO and MMusic are most related WGs. Unfortunately there is
   no one protocol above considered by current P2P streaming

   We claim that PPSP is not a stand-alone protocol. It could and should
   integrate with the existing related protocols to the largest extent.

Zhang                 Expires November 27, 2009               [Page 7]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

   We analyze several protocols PPSP may relate to in detail in section4.

3.4. Mobility and wireless issue

   Mobility and wireless becomes a very important feather to support in
   future internet [GENI],[FIND]. Some operators have also started
   research projects on mobile and wireless Internet. For example, China
   Mobile came out with its DSN (distributed services network) strategy
   last year to build its mobile Internet [draft-zhang-ppsp-dsn-

   Along with the introduction of mobile and wireless characteristics
   into Internet, mobile streaming will become more and more
   popular[MobileTV].In Korea the mobilTV subscriber is 17 million
   accounting one third of the mobile subscriber. In Italy there are 1
   million mobileTV users. In the period of Beijing Olympic games, there
   are more than 1 million usage of China mobile's mobileTV.

   Most of current mobileTV are developed in client/server model. It's a
   natural idea to increase its scalability and decrease the cost by
   deploying P2P mobile streaming.

   However there are a lot of differences in mobile/wireless Internet
   compared with fixed Internet environment. This makes it hard to copy
   current P2P streaming protocol in fixed Internet environment.

3.4.1. End to end communication is harder

   Unlike fixed Internet, it's difficult to realize end-to-end
   communication in mobile Internet. Mobile terminals cannot connect
   with each other directly. The connection must be set up by
   mobile/wireless access nodes. Therefore mobile terminals are hard to
   become peers without the cooperation of mobile/wireless access
   equipments. It's obviously a heavy burden for the mobile/wireless
   access points.

Zhang                 Expires November 27, 2009               [Page 8]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

       |                                                            |
       |                                       +-------+            |
       |                                       | Cache |            |
       |                                       +-------+            |
       |                                           ^                |
       |                                           |                |
       |     Peerlist                              V                |
       |  +---------------+      +----+      +-----------+          |
       |  |   Tracker     |<---->|PEER|<---->|    AP     |Bottleneck|
       |  +---------------+      +----+      +-----------+          |
       |    ^            ^                    ^         ^           |
       |    |            |                    |  Low    |           |
       |    |            |                    |Bandwidth|           |
       |    V            V                    V         V           |
       |  +---+ End-end +---+           +------+     +------+       |
       |  |PC |<------> |PC |           |Mobile|<--->|Mobile|       |
       |  |   |  works  |   |           |Phone |  ?|Phone |       |
       |  +---+  Well   +---+           +------+     +------+       |
       |                                                            |
       |                                                            |
       |                                                            |

                  Figure 1 Mobile Internet communication

3.4.2. Limited Bandwidth resource

   Even if end-to-end communication is ensured, there are still problems
   for P2P mobile streaming.As shown in Figure1, the following bandwidth
   is limited and the transmission cost is relatively high:

     a) between mobile terminals and mobile access nodes;

     b) between mobile access nodes;

     c) between mobile network to fixed network.

It raises some requirements for PPSP:

   1) The overhead of PPSP cannot be much. Because PPSP is a signaling
      protocol, the overhead refers to the ratio of signaling traffic
      with respect to overall streaming traffic. Different solutions
      have different overhead. [Computer Networks-Traffic]analyzes four
      P2P streaming overhead, namely PPLive,PPStream,SOPCast and
      TVAnts.There is a tradeoff consideration in PPSP. We know that
      frequent exchange in bitmap may cause a big overhead but it also

Zhang                 Expires November 27, 2009               [Page 9]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

      enables a small peer cache to keep the smooth play of the program.
      On one hand, the overhead should be minimum to reduce the traffic
      and increase the efficiency so the bitmap exchange frequency
      should be small. On the other hand, a mobile terminal has usually
      small cache size so the bitmap exchange frequency should be large.
      How to solve the conflict and balance between the cache size and
      bitmap exchange frequency is a problem PPSP may face with.

   2) Cross-domain traffic must be reduced. For most mobile Internet
     domains, their network scale is rather smaller compared with the
     Tier1 and Tier2 peering networks. Currently peering networks are
     free from the cross-traffic. However the low-tier ISPs have to pay
     for dual-directional traffic fee even it's a traffic initiated
     from higher tier ISPs. It makes mobile Internet provider worse in
     case  P2P streaming applications generate great traffic with a
     low-cross-domain bandwidth.

3.4.3. Other difference

   Mobility, low battery and capability of mobile terminals make us
   considering more factors in peer selection to ensure smooth streaming.
   A new protocol might therefore allow more information to report for
   trackers to do peer selection.

Zhang                 Expires November 27, 2009              [Page 10]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

4. Design Issues

   This section introduces key issues when designing PPSP.

4.1. Architecture Choice

   There are multiple proposed p2p streaming solutions. Some are used in
   practice and while others are popular in theory. The basic idea of
   P2P streaming is to partition streaming into chunks and peers are
   used in relaying chunk transmission. The solutions can be categorized
   by tree-based and mesh-based [Survey]. The former is ''pushing'' chunks
   to the audience and the latter is enabling the audience to ''pulls''
   the desired chunks from the peers who has.

   In the tree-based p2p streaming, tree construction and maintenance
   can be done in either a centralized or a distributed fashion [Survey].
   In the mesh-based p2p streaming, no specific topology maintenance is
   needed. The task is how to locate and retrieve real-time data from
   multiple sources with different chunks for a streaming. In order to
   realize this, each peer has to actively locate cache and exchange
   chunks from other peers by the guidance of the tracker.

   The biggest challenge in tree-based p2p streaming is two-fold: First,
   the depth of the tree affects the maximum delay the system has;
   Second, tree-based streaming still cannot recovery fast enough to
   handle frequent peer churn. Therefore they are hardly used in
   practice. On the contrary mesh-based p2p streaming is widely used to
   overcome these drawbacks for real deployment, like pplive, ppstream,
   coolstreaming, etc,..

4.2. Integration with existing protocols

   PPSP will not be a stand-alone protocol. A major advantage of a
   standard protocol is that we can explicit consider its interactions
   with other protocols, and design for an integrated system.

   In particular, we identify that PPSP will interact with the following
   protocols: RELAOD, ALTO, and RTSP, where P2PSIP, ALTO and MMusic are
   the most related WGs.

4.2.1. Integration with RELOAD

   RELOAD defined by P2PSIP deals with resource location in end to end
   commutation. The iterative and recursive routing process in RELOAD is
   shown in Fig4, which is different from PPSP. That is, the data stored
   in RELOAD is user profile data and the requester knows exactly what the
   data is (e.g., the location of Alice@chinamobile.com). While in PPSP,

Zhang                 Expires November 27, 2009              [Page 11]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

   there are many peers storing different data pieces of ''CNN Live''. The
   only thing a peer must know is the metadata of the movie. A gossip
   protocol to communicate with other peers is needed to get the real
   data quickly.

             |                 +---------------+              |
             |                 |      Peer     |              |
             |                 +---------------+              |
             |                  ^ |         ^ |               |
             |              1,2 | |1'    3,4| |3'             |
             |                  | |         | |               |
             |                  V V         V V               |
             |        +-------------+  2'  +------------+     |
             |        |    Peer     |----->|    Peer    |     |
             |        +-------------+      +------------+     |
             |                                                |

                          Figure 2 P2PSIP process

   The biggest difference between P2PSIP and PPSP lies in their
   different Search efficiency requirements. PPSP requires retrieving
   real-time/para real-time data and therefore a tree/mesh topology is
   built. DHT based topology supported in RELAOD may not be suitable for
   peer organization.

   Although P2PSIP doesn't fit for streaming peer organization, it can
   be deployed in PPSP environment to some extent.

   First, the topology organization of DHT defined in RELOAD can be used
   to organize multiple trackers. Due to the large population, some
   trackers may cooperatively serve a channel/file. Considering the
   great amount of channels, there are many trackers in practice.
   Because the search time of which channel/file the tracker stores
   accounts small percentage in the whole searching procedure, DHT can
   be used to query for peer list in case of thousand of channels or
   million of files which are hard to use one tracker.

   Second, there is a detailed solution for Firewall/NAT transversal in
   in RELOAD. PPSP faces with the same problem, although not as serious
   as RELAOD because there are lots of peer candidates with public
   addresses. But we can definitely reuse RELAOD in case of NAT/Firewall
   transversal which may occur in mobile environment.

Zhang                 Expires November 27, 2009              [Page 12]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

4.2.2. Integration with ALTO

   ALTO is to define a protocol realizing local traffic mostly for P2P
   applications. The goal of an ALTO solution would be to help peers to
   find the best sources and the best destinations for media flows they
   receive and relay. In [draft-marocco-alto-problem-statement-03], the
   authors mentioned p2p live streaming that can benefit from ALTO

   As we have seen in Section 1, P2P streaming traffic account much on
   the Internet backbone. PPSP has to consider operator-friendly ways to
   reduce the cross-backbone traffic in order to control the
   transmission cost. ALTO is a good candidate to do so.

   ALTO provides a 3rd party to provide peer locality information based
   on the premise that the 3rd party has the knowledge of the network
   topology. In addition there may have extra traffic localization means,
   e.g., in [draft-zhang-alto-traceroute-00], peers can cluster the
   nearby peers by simple and lightweight measurements. We can use this
   mechanism in peer selection to further reduce the traffic.

4.2.3. Encapsulating RTSP

   At a first sight, the function of PPSP protocol is similar to
   traditional client/server streaming control protocols, RTSP. But in
   fact RTSP don't involve the problems PPSP has.

   In RTSP, the focus is to control the streaming, like PLAY, PAUSE;
   however PPSP focuses on signaling peers for real-time resource
   discovery, merge and synchronization instead of how to realize
   streaming control.

   On the other hand, considering the prevalence of RTSP, it can also be
   reused in clients without installing PPSP-compatible software to use
   P2P streaming service.

   The basic idea in that is to set up a proxy node (e.g., using a cache)
   which can act as a RTSP server who is actually a peer of PPSP.

4.2.4. Edge Device such as Cache Integration

   As stated in Section 3, if the widely deployed web cache and CDN
   nodes can be reused in p2p streaming, the video quality, local
   traffic and some security problems may be better solved.[HTPT]
   proposes a solution similar to what we propose in section 4.5 to
   encapsulate and transport them using the HTTP protocol so that they

Zhang                 Expires November 27, 2009              [Page 13]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

   are cacheable.

Zhang                 Expires November 27, 2009              [Page 14]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

5. Scope of Work

   We propose to develop an open peer to peer streaming protocol, namely
   PPSP. The basic task of PPSP is to define a protocol of locating and
   transmitting real-time data efficiently from multiple sources with
   different pieces in peer to peer environment.

   PPSP focuses on how to negotiate with un-preassigned peers for needed
   chunks. Therefore, PPSP is mainly a signaling protocol and the
   protocol stack of PPSP is shown in Figure 3.

                      |    PPSP Application         |
                      |    PPSP Signaling Protocol  |
                      |      Transport Layer        |

                 Figure 3 PPSP Position in Protocol Stack

   In order to locate real-time data efficiently from multiple sources
   with different pieces, we have to solve the following problems:

   1) To standardize the architecture for locating the data efficiently.

   Tracker-based structure is widely used in current p2p streaming
   practice. However some tracker-less structures like DHT peer
   management solutions are also proposed. We need to decide which one
   is better for p2p streaming;

   2) To standardize the signaling interaction process.

   In this part we actually want to standardize client registration
   process (analogous to TCP 3-way handshake procedure), client
   information exchange process (analogous to SIP session setup process)
   and client report process.

   The current tracker-based means is a two-step searching, i.e., peer
   reporting to tracker coarse information about it has. Once the
   tracker is asked, it informs peer of the coarse information; the
   grain information is achieved by peers exchanging bitmap each other.
   Some other means, e.g., peer reporting to tracker grain information
   directly and tracker informs peer of the exact information or DHT
   based searching, should be evaluated. In each proposal we also need
   to define the message format in the interactions.

Zhang                 Expires November 27, 2009              [Page 15]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

   3) To discuss how to incorporate node information such as online time,
   link status, node capability, battery information and some
   application requirements parameters into the protocol to expand the
   peer selection.

   In this part, we actually want to standardize PPSP message headers
   (analogous to IP header definition) and PPSP metadata format
   (analogous to SIP header definition).

Zhang                 Expires November 27, 2009              [Page 16]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

6. Security Considerations

   PPSP has a similar assumption in peer privacy as P2PSIP, i.e., all
   participants in the system are issued unique identities and
   credentials through some mechanism not in the scope of this working
   group, such as a centralized server. Hence the WG will not attempt a
   solution to these issues for P2P streaming networks in general.
   However PPSP has some unique privacy issue different from P2PSIP:

   1) The content published by peers may not be checked by centralized
   certificating server because of the high amount. Therefore P2P
   streaming network faces with more serious malicious content
   distribution danger than P2PSIP.

   2) Content Pollution is a phenomenon P2PSIP may not meet with. But
   these is a common problem faced by P2P streaming and file sharing.
   It's recorded that there are about 50% of the content is polluted in
   file sharing applications. Although it's not as serious as file
   sharing content pollution, it's still a big issue P2P streaming
   applications face with.

   3) Because there is a tracker server who is critical to the P2P
   streaming systems. It has more probability to launch attacks to the

   PPSP may include some security mechanisms to prevent malicious nodes
   to pollute or launch attacks to the tracker. Security issues in PPSP
   need to be further investigated.

7. Acknowledgments

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

8. References

8.1.Normative References

   [Cisco] Approaching the Zettabyte Era by Cisco.

   [PPLive] www.pplive.com

   [PPStream] www.ppstream.com

   [UUSee] www.uusee.com

   [youtube] www.youtube.com

Zhang                 Expires November 27, 2009              [Page 17]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

   [tudou] www.tudou.com

   [CNN] www.cnn.com

   [Octoshape] www.octoshape.com


   [Sigcomm:P2P streaming] Challenges, Design and Analysis of a Large-
   scale P2P-VoD System,Yan Huang et al, Sigcomm08.

   [draft-marocco-alto-problem-statement-03], Application-Layer Traffic
   Optimization (ALTO) Problem Statement, E. Marocco et al, draft-


   [CoolStreaming] CoolStreaming/DONet: A Data-Driven Overlay Network
   for Efficient Live Media Streaming, Xinyan Zhang et al,

   [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin Shen
   et al,


   [GENI] www.geni.net



   [MobileTV] MobileTV,Turning in or switching off, Arthur D. Little

   [Computer Networks:Traffic] Traffic analysis of peer-to-peer IPTV
   communities, Thomas Silverston et al, Computer Networks, 53 (2009)

   [Survey]A survey on peer-to-peer video streaming systems Yong Liu et
   al, Peer-to-Peer Netw Appl (2008) 1:18-                                            -28,Springer.

   [draft-zhang-alto-traceroute-00] www.ietf.org/internet-draft/draft-

Zhang                 Expires November 27, 2009              [Page 18]

Internet-Draft   Problem Statement of P2P Streaming Protocol   May 2009

8.2.Informative References

Author's Addresses

   Yunfei Zhang

   China Mobile Communication Corporation


   Ning Zong

   Huawei Technologies Co., Ltd.


   Gonzalo Camarillo



   James Seng



   Richard Yang

   Yale University


Zhang                 Expires November 27, 2009              [Page 19]