PPSP K. Wu Internet Draft Z. Lei Intended status: BCP D. Chiu Expires: September 2010 ASTRI April 27, 2010 P2P Layered Streaming for Heterogeneous Networks in PPSP draft-wu-ppsp-p2p-layered-streaming-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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." Wu, et al. Expires September 11, 2010 [Page 1] Internet-Draft P2P Layered Streaming March 2010 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 September 11, 2010. 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. 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. Abstract The scenarios where a Peer-to-Peer Streaming Protocol (PPSP) contains heterogeneous nodes need special considerations. For example, mobile devices, PCs and set-top boxes may all need to access and provide service for the same content. To support heterogeneity and maximize the total network utilization, it may be necessary to have layered coding of content to achieve desired results. This document defines the Layered P2P Streaming in PPSP with support for heterogeneous peer nodes. Wu, et al. Expires September 11, 2010 [Page 2] Internet-Draft P2P Layered Streaming March 2010 Table of Contents 1. Introduction................................................3 2. Terminology.................................................5 3. Architecture................................................6 3.1. Function Entities and Interfaces........................6 3.2. Layered Dependency......................................8 3.3. Layered Indication......................................9 4. Message Flows...............................................9 4.1. PUT-LAYER (Put Layer Information) into Tracker...........9 4.2. GET-LAYER (Get Layer Information) from Tracker..........10 4.3. PUT-CHUNK (Put Chunk Information) into Tracker..........11 4.4. GET-PEERLIST (Peer Selection)..........................11 4.5. LAYER-CHANGE (Layer Change)............................12 4.6. STATISTICS............................................13 5. Open issues................................................13 5.1. Data Scheduling........................................13 5.2. System Performance Metrics.............................14 5.2.1. Throughput and Delay..............................14 5.2.2. Layer delivery ratio..............................14 5.2.3. Useless packets ratio.............................14 5.2.4. Jitter prevention.................................14 5.3. User Performance Metrics...............................15 5.3.1. Start-up Delay....................................15 5.3.2. Playback Continuity...............................15 5.3.3. Playback Delay....................................15 6. Deployment Options.........................................16 7. Protocol Detail............................................16 8. Security Considerations.....................................16 9. IANA Considerations........................................16 10. Conclusions...............................................16 11. References................................................16 11.1. Normative References..................................16 11.2. Informative References................................16 12. Acknowledgments...........................................17 1. Introduction Single layer video streaming cannot satisfy heterogeneous customer requirement and heterogeneous download capacity. There are existing systems that use multiple versions of video content (each encoded at different resolution or visual quality) to minimize the overall transmission cost. For example, lower resolution video can be sent to Wu, et al. Expires September 11, 2010 [Page 3] Internet-Draft P2P Layered Streaming March 2010 mobile devices while higher resolution or high quality video is sent to PC or STB players. However, in the P2P network, if there are too many independent video data transmitting, the users' inbound and outbound bandwidth will not be efficiently used [3]. Peers in different versions will not help each other. The overall video quality received will not be optimal. The basic idea of layered encoding is that a video sequence is divided into multiple non-overlapped bit streams, or layers. The base layer contains the basic data representing the most important features of the video [2]. Additional layers, called enhancement layers, contain data that progressively refine the reconstructed video quality. According to the available bandwidth, participating nodes subscribe a subset of the layers to reconstruct the video with certain quality degradation [2]. Layered video has the advantage of bandwidth efficiency and at the same time meets the real-time streaming requirement of peer clients with wide range of variation in processing power, display capability and network conditions. In other words, although heterogeneity exists for peers in the P2P network, an optimal viewing experience can be achieved for each peer based on its own access bandwidth and capabilities. An important requirement for Layered P2P streaming is that both base layer and enhancement layers can be decoded by standard compliant single layer decoders that have already been widely adopted, e.g. H.264/AVC, MPEG-4, etc. It requires minimum codec modifications because for many peer clients (e.g. STB or HMC), its decoder is hard- coded into the IC and cannot be changed at all. Section 2 lists the terminology used. In Section 3 we define the general architecture. Section 4 defines the Layered P2P streaming control message flows. Section 5 discusses the open issues. Section 6 discusses the deployment issues. Section 7 gives out the protocol details by expanding the PPSP streaming protocol to support the layered streaming. Wu, et al. Expires September 11, 2010 [Page 4] Internet-Draft P2P Layered Streaming March 2010 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Multi-layer P2P Streaming: multiple bit streams (layers) of same media content co-exist in the same P2P streaming group/session; each layer corresponds to a different media quality level; peers can choose different layers for decode and playback; Base Layer (BL): unique Base Layer (required by all upper level layers for proper decoding); Enhancement Layer (EL_i): i_th enhancement layer; Heterogeneous peers: peers have different processing power, access bandwidth, or display constraints; Low capacity peers, with low processing power, low access bandwidth or low display capability, e.g. mobile devices. High capacity peers, with high processing power, high access bandwidth or high definition display, e.g. media center PC, or HD Set Top Box. Layered coding: coding scheme that produces multiple layers of media streams for the same content. A higher layer can be decoded only if all the lower layers are available. Generally, layered coding does not lose much video coding efficiency compared with single layer coding streaming. Decode ability: compatibility of the media bit stream that can be correctly decoded by the standard compliant decoders, e.g. H.264/AVC or MPEG-4. Layer Information: It keeps the layer number and the information for each layer. For example, the information contains bitrate, resolution, frame rate, QP factor, etc. A peer can select the suitable layer according to its hardware configuration or network situation. Wu, et al. Expires September 11, 2010 [Page 5] Internet-Draft P2P Layered Streaming March 2010 3. Architecture Layered P2P can be considered a generalized version of single layer P2P. We describe how different components in single layer P2P need to be extended. Same as in single layer P2P, there is a meta file. In layered P2P, the meta file contains a layered content description. A peer doing layered P2P has an important module that determines the number of layers it will subscribe to. This module may take manual input (e.g. the user decides to get base layer only, or to get HD no matter what). If there is no manual input, the module selects an appropriate number of layers to get, based on network conditions. The peer-tracker protocol should allow a peer to indicate which layers are of interest. The tracker will then take that into consideration in returning peer-list. Optionally, the peers in peer- list may come with layer information. The management/status reports from peer to tracker should also indicate layer information about the local peer. Each peer doing layered P2P has a more complicated scheduling module, figuring out which chunks in which layer have higher priority to get. There is no need to standardize the scheduling algorithm. The performance metrics related to this module (e.g. throughput, delay, layer completion ratio, waste ratio etc.) are discussed in later sections. The peer-to-peer protocol for signaling (exchanging bitmap information) needs to have an extension to describe layered bitmaps and related data structures. The peer-to-peer data plane protocol can be almost the same as the single-layer case; the only extension is to add indicator for which layer the requested chunk belongs to. 3.1. Function Entities and Interfaces Layered P2P architecture is extended from the single layer P2P streaming (PPSP) with modification of adding layer_i to meet the layered streaming requirement. Layer_i is the No. of active layer. Wu, et al. Expires September 11, 2010 [Page 6] Internet-Draft P2P Layered Streaming March 2010 Application Layer ======================================================== Communication Layer Peer +-------------------+ |peer signaling |----------------+ | |Data management | | | +============+ |-+--------------+ | +===============+ | |Swarm ID | |Layer Infomation | | | JOIN/LEAVE / | | |[- Chunk ID_i]| | - Layer_i | | | KEEPALIVE / | | | - peer list | | - Bitrate | | | PUT-LAYER / | | | - Buffer map | | - resolution | | | GET-LAYER / | | | | | - frame rate | | | PUT-CHUNK / | | | | | - etc. | | | GET-PEERLIST /| | | | | | | | LAYER-CHANGE /| | | | | | | | STATISTICS) | | | | | | | +===============+ | +============+ | | | +-------------------+ | | | +------------------+ +==============+ ^ -------------------*---------------------------------------------- Tracker V +-------------------+ |tracker signaling | | | | (JOIN/LEAVE/ | | KEEPALIVE / | | PUT-LAYER / | | GET-LAYER / | | PUT-CHUNK / | | GET-PEERLIST / | | LAYER-CHANGE / | | STATISTICS) | +-------------------+ +----------------------------------------------------------+ | Data management on Tracker | | | | +======================+ +======================+ | | |peer status | |content status | | | | peer ID | | +-------------+ | | | | - online time | | | Swarm ID | | | | | - peer property | | | [- Chunk ID_i]| | | | | - link status | | | - peer list| | | | | - etc. | | +-------------+ | | | +======================+ +======================+ | | +======================+ | Wu, et al. Expires September 11, 2010 [Page 7] Internet-Draft P2P Layered Streaming March 2010 | |Layer Infomation | | | |- Layer_i | | | | - Bitrate | | | | - resolution | | | | - frame rate | | | | - etc. | | | +======================+ | +----------------------------------------------------------+ ================================================================== Transport Layer Fig 1 Function Entities of PPSP Tracker Communication Different from the single layer P2P streaming, peer and tracker need to keep the layer information. The following components are considered: 1) Transmission of PUT-LAYER messages, by which source tells trackers the layer information the streaming is using. 2) Transmission of GET-LAYER messages, by which peers request what they want and get the layer information from trackers. 3) Transmission of PUT-CHUNK messages, by which peers tell trackers what they have. The bitfield can represent chunk_i. 4) Transmission of GET-PEERLIST messages, by which peers request what they want and get candidate peers list from trackers. 5) Transmission of STATISTICS requests and responses, by which trackers can get peers status, network performance, layer_i, etc. 3.2. Layered Dependency The upper layers depend on the lower layers. An incomplete lower layer renders all chunks of upper layers useless. Hence, chunks of lower layers always carry high priority than chunks of higher layers. In reality, missing data (or delay of chunk arriving) is impossible to avoid. Certain error handling (e.g. error resilient decode or error concealment) mechanism in the players are needed to make sure errors in one layer won't propagate and destroy the whole upper layers. Wu, et al. Expires September 11, 2010 [Page 8] Internet-Draft P2P Layered Streaming March 2010 Specific techniques used for such error concealment tools are beyond the scope of this document. However, we will give some default mechanisms for handling such cases. A practical Layered P2P system can choose any way to implement it. 3.3. Layered Indication Once a peer determines the highest layer (HL) it will subscribe to, only chunks belong to HL or lower layers are of interest to this local peer. When the peer sends the GET-PEERLIST request, the peer layer flag should be included in the request message. The neighbor peer and tracker will then take the layer information into consideration in returning peerlist. The peers in peerlist may come with layer info. The management/status reports from peer to tracker should also indicate layer info about the local peer. 4. Message Flows 4.1. PUT-LAYER (Put Layer Information) into Tracker When the source put the layer information, tracker will reply an ACK. The layer information keeps the layer number and the information for each layer. Wu, et al. Expires September 11, 2010 [Page 9] Internet-Draft P2P Layered Streaming March 2010 Peer Tracker/Peer | | | | | | | | |Send PUT-LAYER (Put Layer Information) | |----------------------------------------->| | | | | |Reply PUT-LAYER ACK | |<-----------------------------------------| | | | | | | | | | | Figure 2: Get Channel Information from Tracker 4.2. GET-LAYER (Get Layer Information) from Tracker When a peer gets the layer information, the tracker will reply the the layer information. It keeps the layer number and the information for each layer. Peer Tracker/Peer | | | | | | | | |Send GET-LAYER (Get Layer Information) | |----------------------------------------->| | | | | |Reply Layer Information | |<-----------------------------------------| | | | | | | | | Figure 3: Get Channel Information from Tracker Wu, et al. Expires September 11, 2010 [Page 10] Internet-Draft P2P Layered Streaming March 2010 4.3. PUT-CHUNK (Put Chunk Information) into Tracker When a peer puts its chunk information, the tracker will reply an ACK. The chunk information keeps the layer number and the bitfield information for each layer in each chunk. Peer Tracker/Peer | | | | | | | | |Send PUT-CHUNK (Put Chunk Information) | |----------------------------------------->| | | | | |Reply PUT- CHUNK ACK | |<-----------------------------------------| | | | | | | | | Figure 4: Get Channel Information from Tracker 4.4. GET-PEERLIST (Peer Selection) The helpful neighbors of a peer should be those with equal or higher layer peers. When a peer sends the GET-PEERLIST request, the numbers of active layers of the peer should be included in the request message. Each peer's peer selection strategy is based on its own criterion (layers for playback, tolerance for delays, jitter, and other factors, e.g. QoE parameters). The optimal peer selection algorithm is beyond the scope of this document. The document only specifies that there is a peer selection strategy such that Layer ID is part of the parameters, and can be used for data exchange (via buffer map). Wu, et al. Expires September 11, 2010 [Page 11] Internet-Draft P2P Layered Streaming March 2010 Peer Tracker/Peer | | | | | | | | |Send Get Peerlist with its Layer_i | |----------------------------------------->| | | | | |Reply Get Peerlist | |<-----------------------------------------| | | | | | | | | Figure 5: Peer Selection 4.5. LAYER-CHANGE (Layer Change) Peer can select its suitable active layer according to it current network bandwidth. For example, when a peer's bandwidth is high, the peer can request all layer chunks. But when a peer's bandwidth is slow, the peer can request lower layers, or just base layer chunks. When the peer changes its layer state, it will send message to notify its peers and tracker for updating its information. Peer Tracker/Peer | | | | | | | | |Send LAYER-CHANGE | |----------------------------------------->| | | | | |Reply LAYER-CHANGE ACK | |<-----------------------------------------| | | | | | | | | Figure 6: Layer Change Wu, et al. Expires September 11, 2010 [Page 12] Internet-Draft P2P Layered Streaming March 2010 4.6. STATISTICS Peer sends its statistics information (e.g., peers status, network performance, layer_i, etc) to tracker. Peer Tracker | | | | | | | | |Send STATISTICS | |----------------------------------------->| | | | | |Reply STATISTICS ACK | |<-----------------------------------------| | | | | | | | | Figure 6: Statistic 5. Open issues 5.1. Data Scheduling Different coding scheme has different optimal data scheduling strategy. This document does not specify which specific coding scheme to use, except that it has to be compliant with media codec standard (e.g. H.264/AVC or MPEG-4) at each and every layer to avoid a requirement for non-standard compliant decoder in the peer player. A simple greedy data scheduling strategy is proposed in [3] and can be adopted here for layered P2P streaming. Each peer requests lower layers from lower bandwidth neighbors and higher layers from high bandwidth neighbors. This scheduling strategy is proven to be optimal for a given single peer within a certain time slot but may not be globally optimal. Wu, et al. Expires September 11, 2010 [Page 13] Internet-Draft P2P Layered Streaming March 2010 5.2. System Performance Metrics Although the layered encoding scheme brings more flexibility for participating peers to achieve adaptive video quality, it also causes challenges to the P2P protocol for layer streaming. In the paper [2], the following four performance metrics are mentioned. 5.2.1. Throughput and Delay It is the basic requirement that the overall P2P network can maximize the overlay throughput and keep low packet delay. [2] 5.2.2. Layer delivery ratio In single layered P2P streaming, maximizing the node delivery ratio is almost equal to maximizing the throughput. But it is not the case in layered streaming. In multiple layered P2P streaming, subscribing many layers but with low delivery ratio for each layer can result in high throughput. But, the video quality cannot be high because of the layer dependency. Therefore, it is a key point to ensure high delivery ratio for subscribed layers. [2] 5.2.3. Useless packets ratio According to the layered encoding/decoding scheme, the decoding of upper layers depends on the availability of lower layers. If some lower layer packets are missed, the packets with the same sequence IDs in the upper layers cannot be correctly decoded. The upper layer packets become useless. Therefore, it is a key point that the useless packet ratio should be kept low. [2] 5.2.4. Jitter prevention Because Internet is a dynamic environment, the bandwidth variation is common in P2P network. If the node subscribes more layers immediately after bandwidth increased, it may have to drop the high layers after a short while according to the bandwidth decreasing. This short-term subscribe-drop pair is called jitter. Jitter brings fluctuation in quality of service (QoS) and causes its buffer overflow or underflow. Wu, et al. Expires September 11, 2010 [Page 14] Internet-Draft P2P Layered Streaming March 2010 Therefore, jitter should be considered for being prevented by the data scheduling design. [2] 5.3. User Performance Metrics A set of QoE parameters, e.g. layers for playback, peer preference, tolerance of artifacts (e.g. delay, jitter, freeze, or error blocks effect) etc., may be defined and implemented as system tools inside or outside of the P2P layered streaming. The peer selection criterion can make best use of such information to make sure that it can obtain its optimal playback layer from the right peers. One of the important goals for layered P2P streaming is to enhance the overall user quality of experience by designing the p2p streaming protocol to utilize the heterogeneous conditions of participating peers. For example, the start-up delay is the duration between a peer makes its request for a stream and the stream actually begins to play at the peer. Layered P2P streaming can reduce the start-up delay by serving the BL (Base Layer) first to the peer while enhancement layers may be delivered later with lower priority. The playback continuity and playback delay can be set as quality metrics as well by the P2P network to dynamically adjust for performance tuning or tradeoff between various quality metrics. Several quality metrics may be considered in Layered PPSP for live streaming and progressing downloading. 5.3.1. Start-up Delay The start-up delay is the duration between a peer makes a request for a stream and the stream actually begins to play at the peer. 5.3.2. Playback Continuity Playback continuity is the percentage of the playing streaming successfully played at the correct time. 5.3.3. Playback Delay Playback delay is the delay between a streaming chunk which is generated by the source and the streaming chunk being viewed by the peer. Wu, et al. Expires September 11, 2010 [Page 15] Internet-Draft P2P Layered Streaming March 2010 6. Deployment Options Todo: The content of this section need further input. 7. Protocol Detail Todo: The content of this section need further input. 8. Security Considerations Todo: The content of this section need further input. 9. IANA Considerations Todo: The content of this section need further input. 10. Conclusions According to the characteristics of P2P layered coding, we propose the P2P layered streaming protocol in the PPSP framework. 11. References 11.1. Normative References [1] Yingjie Gu, et. al. Tracker Protocol, PPSP (drafting). 11.2. Informative References [2] LayeredP2P: A New Data Scheduling Approach for Layered Streaming in Heterogeneous Networks. Xin Xiao, Yuanchun Shi, Yuan Gao and Qian Zhang. Infocom 2009 Wu, et al. Expires September 11, 2010 [Page 16] Internet-Draft P2P Layered Streaming March 2010 [3] PALS: Peer-to-Peer Adaptive Layered Streaming. Reza Rejaie, Antonio Ortega. NOSSDAV, 2003. [4] Layered Peer-to-Peer Streaming. Yi Cui, Klara Nahrstedt. NOSSDAV, 2003 12. Acknowledgments Wu, et al. Expires September 11, 2010 [Page 17] Internet-Draft P2P Layered Streaming March 2010 Authors' Addresses Kent Kangheng Wu Hong Kong Applied Science and Technology Research Institute Company Limited (ASTRI) 3/F, Building 6, 2 Science Park West Avenue, Hong Kong Science park, Shatin, New Territories, Hong Kong Phone: 852-34062908 Email: khwu@astri.org James Zhibin Lei Hong Kong Applied Science and Technology Research Institute Company Limited (ASTRI) 3/F, Building 6, 2 Science Park West Avenue, Hong Kong Science Park, Shatin, New Territories, Hong Kong Phone: 00852-34062748 Email: lei@astri.org Dah Ming Chiu Hong Kong Applied Science and Technology Research Institute Company Limited (ASTRI) 3/F, Building 6, 2 Science Park West Avenue, Hong Kong Science Park, Shatin, New Territories, Hong Kong Phone: 00852-34062979 Email: dmchiu@ie.cuhk.edu.hk Wu, et al. Expires September 11, 2010 [Page 18]