One document matched: draft-seedorf-ppsp-design-considerations-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?rfc strict="yes"?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes" ?>
<?rfc symrefs="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="info" ipr="trust200902">
  <front>
    <title abbrev="PPSP Design">Design Considerations for a Peer-to-Peer
    Streaming Protocol</title>

    <author fullname="Jan Seedorf" initials="J." surname="Seedorf">
      <organization abbrev="NEC">NEC Laboratories Europe, NEC Europe
      Ltd.</organization>

      <address>
        <postal>
          <street>Kurfuersten-Anlage 36</street>

          <city>Heidelberg</city>

          <code>69115</code>

          <country>Germany</country>
        </postal>

        <phone>+49 (0) 6221 4342 221</phone>

        <email>jan.seedorf@neclab.eu</email>

        <uri>http://www.nw.neclab.eu</uri>
      </address>
    </author>

    <author fullname="Martin Stiemerling" initials="M." surname="Stiemerling">
      <organization abbrev="NEC">NEC Laboratories Europe / University of
      Goettingen</organization>

      <address>
        <postal>
          <street>Kurfuersten-Anlage 36</street>

          <city>Heidelberg</city>

          <code>69115</code>

          <country>Germany</country>
        </postal>

        <phone>+49 (0) 6221 4342 113</phone>

        <email>martin.stiemerling@neclab.eu</email>

        <uri>http://ietf.stiemerling.org</uri>
      </address>
    </author>

    <date year="2010" />

    <area>Transport</area>

    <workgroup>PPSP</workgroup>

    <abstract>
      <t>Streaming video on P2P overlays puts extremely high demands and
      stress on the underlying network, especially in case of TV and live
      streaming. The EU research project NAPA-WINE has devised an overall
      architecture for live video streaming that supports the needs of the
      users and content providers, while being respective of network-level
      needs, as reducing inter-AS traffic using ALTO-like services. In this
      document, we describe generic elements of this software architecture for
      P2P live streaming and derive the corresponding implications for
      standardizing a Peer-to-Peer streaming protocol.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>In recent years, Peer-to-peer (P2P) technology became increasingly
      popular for video streaming applications, including TV services
      (P2P-TV). Examples of commercial P2P-TV include SopCast, TVAnts, PPLive,
      UUSee, and TVUplayer. The interest of the research and standardization
      communities, content providers and network operators is also on the
      rise. Content providers see a novel opportunity to reach users, but at
      the same time they are concerned about the threats posed to their
      standard business models. Network operators are mainly worried by the
      stress posed by such a bandwidth-hungry and delay sensitive application
      on their infrastructure. The research community is stimulated by the
      opportunities offered by live P2P distribution and broadcasting, looking
      both for novel technical solutions and innovative business models.</t>

      <t>NAPA-WINE (Network Aware P2P-TV Application over WIse NEtworks) is a
      three years project (STREP) within the 7-th Research Framework of the
      European Commission whose goal is finding innovative solutions for P2P
      live streaming to meet opportunities envisaged by content providers
      while soothing worries of network operators.</t>

      <t>In a P2P-TV system, a source divides the video stream into chunks of
      data, which are exchanged among nodes to distribute them to all
      participating peers. Peers form an overlay topology at the application
      layer, where neighbor peers are connected and exchange chunks using the
      underlying IP network. The IP and overlay layer are both
      “network” layers in that they both perform routing and
      forwarding of the data: packets in the IP layer and chunks (normally a
      sequence of packets) in the overlay. In this context, the NAPA-WINE
      project has developed an innovative, network cooperative P2P
      architecture that explicitly targets the optimization of the quality
      perceived by the users while minimizing the impact on the underlying
      transport network. Our architecture does not impose any structure on the
      overlay topology, which can be any type of generic mesh. The video
      distribution is chunk-based, but chunk construction is free enough to
      accommodate anything from a single video frame (even less if required)
      to large swaths of a video in case of nearly on-demand applications. The
      focus is on the design of a system empowering future P2P High Quality
      TV, a system where a source peer produces the video stream, chops it
      into chunks, and injects them in the overlay where peers cooperate to
      distribute them, without the need for the source to have enormous
      resources and bandwidth to support the service.</t>

      <t>In this document, we summarize our architecture for P2P live
      streaming (a more detailed description can be found in <xref
      target="refs.napa-architecture"></xref>). The goal of this draft is to
      derive the implications for standardizing a P2P-based streaming protocol
      from the aforemetioned architecture. We thus highlight key design
      considerations for a P2P-based streaming protocol which we believe are
      important input to the IETF PPSP working group.</t>
    </section>

    <section anchor="architecture"
             title="An Architecture for a P2P-based Live Streaming Application">
      <t>The architecture we developed is based on five main building blocks:
      <list style="symbols">
          <t>Application Layer</t>

          <t>Topology Management</t>

          <t>Chunk Scheduling</t>

          <t>Monitoring Layer</t>

          <t>Messaging Layer</t>
        </list> In addition, our architecture contains an external ALTO
      interface that can support the topology management providing information
      that cannot be measured at the application level. In the following we
      briefly outline the role and key features of each building block.</t>

      <section anchor="app-layer" title="Application Layer">
        <t>The Application Layer (or User Layer) is mainly responsible for of
        video encoding and its packaging into chunks (at the source) and
        de-chunkization and decoding at receivers. Standard encoding tools
        like ffmpeg can be used by the User Layer, whose goal is not
        implementing a proprietary video encoder, but supporting as many as
        possible standard formats (MPEG1/2/4, H.264, etc.). Depending on the
        type of video source this may include analog/digital conversion,
        encoding and any other video manipulation that the content provider
        whishes to do, like advertising introduction and similar.</t>

        <t>The standardization of the application layer is out-of-scope for
        IETF PPSP work other than considerations on how to express and
        transport metadata information about the content.</t>
      </section>

      <section anchor="top-manr" title="Topology Management">
        <t>A P2P-TV client needs to communicate efficiently with other peers
        to receive and redistribute the huge amount of information embedded in
        a video stream. Information must arrive in nearly real-time and with
        small delay variation. The application goal is then to deliver all the
        video information to all peers in the system in the smallest possible
        amount of time. One of the key enabling factors is who are the peers
        to communicate with, i.e. the neighborhood selection.</t>

        <t>The overlay network in P2P systems is the result of a distributed
        algorithm that builds and maintains the neighborhood at each peer.
        When a peer joins the system, it selects an initial set of neighbors,
        then the set of neighbors of every node in the system is dynamically
        optimized over time. The bootstrapping phase can be helped by the
        source or a web server where the user selects a channel, which can
        behave as a bit-torrent like tracker. The maintenance of the topology
        is based on a gossiping protocol that enables discovery of peers in
        the overlay. Once peers are discovered, the optimal topology
        management is obtained through an topology manager which chooses which
        peers to connect to.</t>

        <t>IMPLICATIONS ON STANDARDIZATION:<list style="symbols">
            <t>A tracker protocol is required that supports the goals of the
            topology management</t>

            <t>The topology management algorithm can be standardized, but this
            would probably be beyond the scope of the PPSP WG</t>

            <t>The definition of information about the employed topology
            management and the exchange as part of the PPSP WG can be
            standardized</t>
          </list></t>
      </section>

      <section anchor="chunk-sched" title="Chunk Scheduling">
        <t>Strictly related to topology management is the problem of chunk
        trading. The goal of chunk trading is receiving the stream smoothly
        (and with small delay) and to cooperate in the distribution
        procedure.</t>

        <t>Chunks transferring is the operation that most affects performance
        and network friendliness. It includes protocol and algorithmic
        problems. First of all, peers need to exchange information about their
        current status to enable scheduling decisions. The information
        exchanged refers to the state of the peer with respect to the flow,
        i.e., a map of which chunks are needed by a peer to smoothly playout
        the stream. This task means i) sending buffer maps to other nodes with
        the proper timing, ii) receiving them from other nodes and merging the
        information in the local buffer map data base, iii) negotiating if
        this and other information should be spread by gossiping protocols or
        not, and to which depth it should spread in the topology.</t>

        <t>Besides the buffer map exchange, the signaling includes
        Offer/Request/Select primitives used to trade chunks. These messages
        can be piggybacked on chunks for efficiency. Another key protocol
        decision is about "Pushing" or "Pulling" information. A chunk is
        pushed when the peer owning the chunk decides to offer it to some
        other peer, while it is pulled when a peer needing the chunk requests
        it from another peer. From a theoretical point of view, as shown in
        <xref target="refs.opt-scheduling"></xref>, pushing is more effective.
        Regardless of the protocol and the signaling strategy used, the core
        of a scheduler is the algorithm to choose the chunks to be exchanged
        and the peers to communicate with. Many different strategies have been
        studied, including both fundamental algorithms and their adaptation to
        heterogeneous scenarios, multiple sub-streams etc.</t>

        <t>IMPLICATIONS ON STANDARDIZATION:<list style="symbols">
            <t>The PPSP protocol design should allow to operate either with a
            push or pull regime</t>

            <t>The PPSP protocol design should allow to select if push or pull
            is used in the PPSP system during runtime</t>

            <t>The PPSP protocol design should allow to employ multiple chunk
            scheduling algorithms with the same protocol</t>
          </list></t>
      </section>

      <section anchor="mon-layer" title="Monitoring Layer">
        <t>Beside the information provided by e.g. an ALTO Server, both the
        chunk scheduler and the overlay manager can exploit timely information
        about the quality of the connectivity between peers collected in real
        time by monitoring modules. This includes, but is not limited to, the
        distance and the available bandwidth between two peers, or the
        presence of Network Address Translation (NAT). The Monitoring Layer
        may employ passive or active measurement. Passive measurements are
        performed by observing the messages that are exchanged between peers.
        Active measurements craft special probe messages which are sent to
        other peers at the discretion of the Monitoring Layer. Monitoring the
        network conditions is important for the peer-to-peer streaming
        application in order to judge the current state of the surrounding
        network environment</t>

        <t>IMPLICATIONS ON STANDARDIZATION:<list style="symbols">
            <t>The PPSP protocol should allow the exchange of monitoring
            status information (e.g., in the spirit of "Do you see what I
            see?" <xref target="refs.dywis"></xref>)</t>

            <t>The PPSP protocol should support active and passive
            measurements between peers</t>
          </list></t>
      </section>

      <section anchor="mess-layer" title="Messaging Layer">
        <t>The Messaging Layer offers primitives to other modules for sending
        and receiving data to/from other peers. It provides an abstract
        interface to transport protocols (UDP/TCP) and the corresponding
        service access points offered by the operating system by extending
        their capabilities and providing an application level addressing,
        i.e., assigning a unique identifier to each peer. For example, it
        provides the ability to send a chunk to another peer, which has to be
        segmented and then reassembled to fit into UDP datagrams. The
        messaging layer also provides an interface to the monitoring module
        invoked for passive measurements: whenever a message is sent or
        received an indication will be given to the monitoring module, which
        can update its statistics. The last important feature of the messaging
        layer is mechanisms for the traversal of NAT boxes.</t>

        <t>IMPLICATIONS ON STANDARDIZATION:<list style="symbols">
            <t>The PPSP protocol should allow to negotiate or select different
            transport protocols, e.g., between plain TCP and LEDBAT.</t>

            <t>The PPSP protocol or framework should support peers in NAT
            traversal.</t>
          </list></t>
      </section>
    </section>

    <section anchor="summary"
             title="Summary of Considerations for PPSP Protocol Design">
      <t>Future versions of this draft will summarize the key design
      considerations for a PPSP protocol in this section.</t>
    </section>

    <section anchor="conclusions" title="Conclusions">
      <t>Video Streaming applications exploiting the P2P communication
      paradigm are a commercial reality, but their overall architecture is
      still biased by file-sharing applications and they operate without any
      coordination with the IP network, often resulting in poor, even wasteful
      resource usage. This will prevent them to support High Quality TV in the
      future, or to make the transition to High Definition, which will require
      several Mbit/s per peer.</t>

      <t>This document presented the NAPA-WINE architecture for a P2P-TV
      system, which has been developed with the goal of efficiency and
      cooperation between the application and both the network operators and
      the content providers. Prototypes of the peers and system are already
      running on the Internet and are demonstrated at major venues <xref
      target="refs.demo-iptcomm2010"></xref> <xref
      target="refs.demo-p2p2010"></xref>.</t>

      <t>The overlay topology management and the chunk scheduling of
      information have been identified as important features for the
      application to be network-friendly. The first function enables building
      efficient and rational overlay topologies that are correctly mapped on
      top of the transport network structure (e.g., considering minimal number
      of hops between neighbors, locality w.r.t. Autonomous Systems, etc.).
      The second function guarantees that the network capacity is exploited
      without waste (e.g., by minimizing retransmissions and pursuing an
      efficient distribution of chunks, etc.).</t>

      <t>Based on our experience in designing and implementing a P2P live
      streaming system, we highlighted key implications for standardization.
      We believe that these key design considerations we derived based on our
      architecture will be important input to the IETF PPSP working group for
      standardizing a P2P live streaming protocol.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>Security considerations will be detailed in future versions of this
      draft.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>The authors would like to thank all the people participating in
      NAPA-WINE and contributing to the project success with their work and
      research.</t>

      <t>Jan Seedorf is partially supported by the NAPA-WINE project
      (Network-Aware P2P-TV Application over Wise Networks,
      http://www.napa-wine.org), a research project supported by the European
      Commission under its 7th Framework Program (contract no. 214412). The
      views and conclusions contained herein are those of the authors and
      should not be interpreted as necessarily representing the official
      policies or endorsements, either expressed or implied, of the NAPA-WINE
      project or the European Commission.</t>

      <t>Martin Stiemerling is partially supported by the COAST project
      (COntent Aware Searching, retrieval and sTreaming,
      http://www.coast-fp7.eu), a research project supported by the European
      Commission under its 7th Framework Program (contract no. 248036). The
      views and conclusions contained herein are those of the authors and
      should not be interpreted as necessarily representing the official
      policies or endorsements, either expressed or implied, of the COAST
      project or the European Commission.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <reference anchor="refs.napa-architecture">
        <front>
          <title>Architecture of a Network-Aware P2P-TV Application: the
          NAPA-WINE Approach</title>

          <author fullname="R. Birke" initials="R." surname="Birke">
            <organization />
          </author>

          <author fullname="E. Leonardi" initials="E." surname="Leonardi">
            <organization />
          </author>

          <author fullname="M. Mellia" initials="M." surname="Mellia">
            <organization />
          </author>

          <author fullname="A. Bakay" initials="A." surname="Bakay">
            <organization />
          </author>

          <author fullname="T. Szemethy" initials="T." surname="Szemethy">
            <organization />
          </author>

          <author fullname="C. Kiraly" initials="C." surname="Kiraly">
            <organization />
          </author>

          <author fullname="R. Lo Cigno" initials="R." surname="Lo Cigno">
            <organization />
          </author>

          <author fullname="F. Mathieu" initials="F." surname="Mathieu">
            <organization />
          </author>

          <author fullname="L. Muscariello" initials="L."
                  surname="Muscariello">
            <organization />
          </author>

          <author fullname="S. Niccolini" initials="S." surname="Niccolini">
            <organization />
          </author>

          <author fullname="J. Seedorf" initials="J." surname="Seedorf">
            <organization />
          </author>

          <author fullname="G. Tropea" initials="G." surname="Tropea">
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="IEEE Communication Magazine, to appear" />
      </reference>

      <reference anchor="refs.opt-scheduling">
        <front>
          <title>On the Optimal Scheduling of Streaming Applications in
          Unstructured Meshes</title>

          <author fullname="L. Abeni" initials="L." surname="Abeni">
            <organization />
          </author>

          <author fullname="C. Kiraly" initials="C." surname="Kiraly">
            <organization />
          </author>

          <author fullname="R. Lo Cigno" initials="R." surname="Lo Cigno">
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="IFIP Networking 2009" />
      </reference>

      <reference anchor="refs.demo-iptcomm2010">
        <front>
          <title>Prototypical Implementation of ALTO Client and ALTO Server
          and Integration into a P2P Live Streaming Software</title>

          <author fullname="J. Seedorf" initials="J." surname="Seedorf">
            <organization />
          </author>

          <author fullname="S. Niccolini" initials="S." surname="Niccolini">
            <organization />
          </author>

          <author fullname="R. Lo Cigno" initials="R." surname="Lo Cigno">
            <organization />
          </author>

          <author fullname="C. Kiraly" initials="C." surname="Kiraly">
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="Demonstration, IPTComm 2010" />
      </reference>

      <reference anchor="refs.demo-p2p2010">
        <front>
          <title>Network Friendly P2P-TV: The Napa-Wine Approach</title>

          <author fullname="L. Abeni" initials="L" surname="Abeni">
            <organization />
          </author>

          <author fullname="A. Bakay" initials="A." surname="Bakay">
            <organization />
          </author>

          <author fullname="M. Biazzini" initials="M." surname="Biazzini">
            <organization />
          </author>

          <author fullname="R. Birke" initials="R." surname="Birke">
            <organization />
          </author>

          <author fullname="E. Leonardi" initials="E." surname="Leonardi">
            <organization />
          </author>

          <author fullname="R. Lo Cigno" initials="R." surname="Lo Cigno">
            <organization />
          </author>

          <author fullname="C. Kiraly" initials="C." surname="Kiraly">
            <organization />
          </author>

          <author fullname="M. Mellia" initials="M." surname="Mellia">
            <organization />
          </author>

          <author fullname="S. Niccolini" initials="S." surname="Niccolini">
            <organization />
          </author>

          <author fullname="J. Seedorf" initials="J." surname="Seedorf">
            <organization />
          </author>

          <author fullname="T. Szemethy" initials="T." surname="Szemethy">
            <organization />
          </author>

          <author fullname="G. Tropea" initials="G." surname="Tropea">
            <organization />
          </author>
        </front>

        <seriesInfo name=""
                    value="Live Demonstration and Extended Abstract, IEEE P2P 2010" />
      </reference>

      <reference anchor="refs.dywis">
        <front>
          <title>Distributed Self Fault-Diagnosis for SIP Multimedia
          Applications</title>

          <author fullname="X. Miao" initials="X." surname="Miao">
            <organization />
          </author>

          <author fullname="Henning Schulzrinne" initials="H"
                  surname="Schulzrinne">
            <organization />
          </author>

          <author fullname="Vishal Kumar Singh" initials="V.K."
                  surname="Singh">
            <organization />
          </author>

          <author fullname="Qianni Deng" initials="Q." surname="Deng">
            <organization />
          </author>
        </front>

        <seriesInfo name=""
                    value="Springer Real-Time Mobile Multimedia Services, 2007" />
      </reference>
    </references>
  </back>
</rfc>