Design Considerations for a Peer-to-Peer Streaming Protocol
draft-seedorf-ppsp-design-considerations-00

Abstract

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.

Status of this Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on April 21, 2011.

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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 Simplified BSD License.

Table of Contents

1.  Introduction
2.  An Architecture for a P2P-based Live Streaming Application
    2.1.  Application Layer
    2.2.  Topology Management
    2.3.  Chunk Scheduling
    2.4.  Monitoring Layer
    2.5.  Messaging Layer
3.  Summary of Considerations for PPSP Protocol Design
4.  Conclusions
5.  Security Considerations
6.  Acknowledgements
7.  Informative References
§  Authors' Addresses

1.  Introduction

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.

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.

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.

In this document, we summarize our architecture for P2P live streaming (a more detailed description can be found in [refs.napa‑architecture] (Birke, R., Leonardi, E., Mellia, M., Bakay, A., Szemethy, T., Kiraly, C., Lo Cigno, R., Mathieu, F., Muscariello, L., Niccolini, S., Seedorf, J., and G. Tropea, “Architecture of a Network-Aware P2P-TV Application: the NAPA-WINE Approach,” .)). 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.

2.  An Architecture for a P2P-based Live Streaming Application

The architecture we developed is based on five main building blocks:

• Application Layer
• Topology Management
• Chunk Scheduling
• Monitoring Layer
• Messaging Layer

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.

2.1.  Application Layer

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.

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.

2.2.  Topology Management

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.

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.

IMPLICATIONS ON STANDARDIZATION:

• A tracker protocol is required that supports the goals of the topology management
• The topology management algorithm can be standardized, but this would probably be beyond the scope of the PPSP WG
• The definition of information about the employed topology management and the exchange as part of the PPSP WG can be standardized

2.3.  Chunk Scheduling

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.

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.

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 [refs.opt‑scheduling] (Abeni, L., Kiraly, C., and R. Lo Cigno, “On the Optimal Scheduling of Streaming Applications in Unstructured Meshes,” .), 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.

IMPLICATIONS ON STANDARDIZATION:

• The PPSP protocol design should allow to operate either with a push or pull regime
• The PPSP protocol design should allow to select if push or pull is used in the PPSP system during runtime
• The PPSP protocol design should allow to employ multiple chunk scheduling algorithms with the same protocol

2.4.  Monitoring Layer

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

IMPLICATIONS ON STANDARDIZATION:

• The PPSP protocol should allow the exchange of monitoring status information (e.g., in the spirit of "Do you see what I see?" [refs.dywis] (Miao, X., Schulzrinne, H., Singh, V., and Q. Deng, “Distributed Self Fault-Diagnosis for SIP Multimedia Applications,” .))
• The PPSP protocol should support active and passive measurements between peers

2.5.  Messaging Layer

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.

IMPLICATIONS ON STANDARDIZATION:

• The PPSP protocol should allow to negotiate or select different transport protocols, e.g., between plain TCP and LEDBAT.
• The PPSP protocol or framework should support peers in NAT traversal.

3.  Summary of Considerations for PPSP Protocol Design

Future versions of this draft will summarize the key design considerations for a PPSP protocol in this section.

4.  Conclusions

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.

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 [refs.demo‑iptcomm2010] (Seedorf, J., Niccolini, S., Lo Cigno, R., and C. Kiraly, “Prototypical Implementation of ALTO Client and ALTO Server and Integration into a P2P Live Streaming Software,” .) [refs.demo‑p2p2010] (Abeni, L., Bakay, A., Biazzini, M., Birke, R., Leonardi, E., Lo Cigno, R., Kiraly, C., Mellia, M., Niccolini, S., Seedorf, J., Szemethy, T., and G. Tropea, “Network Friendly P2P-TV: The Napa-Wine Approach,” .).

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

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.

5.  Security Considerations

Security considerations will be detailed in future versions of this draft.

6.  Acknowledgements

The authors would like to thank all the people participating in NAPA-WINE and contributing to the project success with their work and research.

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.

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.

7. Informative References

Authors' Addresses