One document matched: draft-wu-ppsp-p2p-layered-streaming-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 15:16:46 |