Usage of the Peer-to-Peer Streaming Protocol (PPSP)
draft-zhang-ppsp-usage-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Hong-Ke Zhang , Di Wu , Mi Zhang , Fei Song | ||
| Last updated | 2014-06-30 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhang-ppsp-usage-00
PPSP Hongke Zhang
Internet Draft Di Wu
Intended status: Informational Mi Zhang
Expires: January 1, 2015 Fei Song
Beijing Jiaotong University
July 1, 2014
Usage of the Peer-to-Peer Streaming Protocol (PPSP)
draft-zhang-ppsp-usage-00.txt
Abstract
This document describes several crucial operation issues of Peer-to-
Peer Streaming Protocol (PPSP) usage, considering two basic modes:
Leech mode and Seed mode. Related parameters setting for default PPSP
scenario are also given from tracker protocol and peer protocol
respectively. In addition, the limitations and gaps of current PPSP
system are identified from the standpoint of satisfying PPSP
requirements.
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 January 1, 2015.
Zhang, et al. Expires January 1, 2015 [Page 1]
Internet-Draft Usage of PPSP July 2014
Copyright Notice
Copyright (c) 2014 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 ................................................ 3
2. Terminology ................................................. 3
3. Operation of PPSP System .................................... 3
3.1. Operation Overview ..................................... 4
3.2. Operation Illustration ................................. 4
4. Suggestions for Parameters Setting in PPSP System .......... 10
4.1. Parameters Setting in Tracker Protocol ................ 10
4.2. Parameters Setting in Peer Protocol ................... 10
5. Limitations and Gaps Analysis .............................. 11
6. Security Considerations .................................... 12
7. IANA Considerations ........................................ 12
8. References ................................................. 13
8.1. Normative References .................................. 13
8.2. Informative References ................................ 13
9. Acknowledgments ............................................ 13
Zhang, et al. Expires January 1, 2015 [Page 2]
Internet-Draft Usage of PPSP July 2014
1. Introduction
The Peer-to-Peer Streaming Protocol (PPSP) supports either live or
Video on Demand (VoD) streaming, which consists of two basic
protocols: the PPSP peer protocol [I-D.ietf-ppsp-peer-protocol] and
the PPSP tracker protocol [I-D.ietf-ppsp-base-tracker-protocol]. Both
of them are proposed from individual perspective based on PPSP
structure. However, it is hard for end users to understand the whole
workflow and parameter setting when combining the tracker and peer
protocols together in reality. More importantly, the potential
limitations of current system should also be considered and
demonstrated to the community.
The tracker protocol modeled as a request/response protocol handles
the initial and periodic exchange of meta-information between
trackers and peers. The peer protocol is supposed to run as a gossip-
like protocol controls the signaling and the media data transfer
between the peers. It currently runs on top of UDP using LEDBAT for
congestion control.
This document describes several crucial operation issues of PPSP
usage, considering two basic modes: Leech mode and Seed mode. Related
parameters setting for default PPSP scenario are also given from
tracker protocol and peer protocol respectively. In addition, the
limitations and gaps of current PPSP system are identified from the
standpoint of satisfying PPSP requirements.
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 [RFC2119].
The document makes extensive use of the terminology and definitions
inherited from Concepts and Terminology for PPSP peer protocol [I-
D.ietf-ppsp-peer-protocol] and PPSP-TP/1.0 [I-D.ietf-ppsp-base-
protocol] in this document.
3. Operation of PPSP System
Different with previous protocol-related drafts, the operation
process of PPSP system in this document focuses on how to combine
multiple entities, such as peers, trackers, portals, etc., and
achieve corresponding functions. Both macroscopic overview and
specific steps are provided in the following sections.
Zhang, et al. Expires January 1, 2015 [Page 3]
Internet-Draft Usage of PPSP July 2014
3.1. Operation Overview
The PPSP supports either live or VoD streaming, which consists of two
protocols: the PPSP tracker protocol and the PPSP peer protocol.
The tracker refers to a directory service that maintains a list of
peers participating in a specific audio/video channel or in the
distribution of a streaming file. It is a logical component, which
can be centralized or distributed, and in this document it will be
treated as a single logical entity.
The peer refers to a participant in a P2P streaming system that not
only receives streaming content, but also caches and streams
streaming content to other participants. Based on the properties of
peers, there are two different modes (Leech mode and Seed mode) in
PPSP. The operation details will be described in Section 3.2.
The basic communication unit of PPSP is the message. In the peer
protocol, multiple messages are typically multiplexed into a single
datagram in transmission process. And in the PPSP system, there are
several rules MUST be obeyed.
1. In the same swarm, peers MUST use the same chunk addressing method
and the same encoding type to ensure that peers can communicate with
each other smoothly.
2. The portal needs to select an appropriate tracker supporting the
same encoding type as the peer. Besides, the portal needs to
distinguish the VoD from live streaming content and then selects the
appropriate tracker to peer.
3.2. Operation Illustration
The normal operation process of the PPSP system is illustrated in
Figure 1. The related entities and elements are described as follows:
Tracker: A logical entity that provides the peer list to peers.
Portal: A logical entity that provides the Media Presentation
Description (MPD) files to peers.
Peer A: A peer that has content resource and wants to share it with
others. (PeerMode is of Seed)
Peer B: A peer that wants to join swarm x to obtain the content
provided by Peer A. (PeerMode is of Leech)
Zhang, et al. Expires January 1, 2015 [Page 4]
Internet-Draft Usage of PPSP July 2014
+-------+ +------+ +------+ +------+ +------+ +------+
|Tracker| |Portal| |Peer A| |Peer B| |Peer C| |Peer D|
+-------+ +------+ +------+ +------+ +------+ +------+
| | | | | |
|<-CONNECT(Join Swarm x)| | | |
|--------OK------------>| | | |
|<----STAT_REPORT-------| | | |
|---------OK----------->| | | |
: : | | |
| |<-----Select Swarm x----| | |
| |--------OK+MPD(x)------>| | |
|<-------CONNECT(Join Swarm x)-------| | |
|------------OK+PeerList------------>| | |
: : | |
| |<-HANDSHAKE-| | |
| |--HS+HAVE-->| | |
| |<-PER_REQ---| | |
| |--PER_RES-->| | |
| | |-HANDSHAKE->| |
| | |-------HANDSHAKE------>|
|<-----STAT_REPORT------| | | |
|----------OK---------->| |<-HS+HAVE---| |
: : |<----HS+HAVE+CHOKE-----|
| |<--REQUEST--|--REQUEST-->| |
| |---DATA---->|<----DATA---| |
| |<--ACK,HAVE-|-ACK,HAVE-->| |
| : : : |
|<---------STAT_REPORT---------------| |
|-------------OK-------------------->|<--------UNCHOKE-------|
| | |---------REQUEST------>|
: | :<---------DATA---------|
| | |---------ACK,HAVE----->|
: |<---HAVE----|----HAVE--->| |
| | |<--REQUEST--| |
| | |<--------REQUEST-------|
| | |----DATA--->| |
| | |----------DATA-------->|
| : : : :
| |<-KEEPALIVE-|-KEEPALIVE->| |
| | |--------KEEPALIVE----->|
|<-------------------STAT_REPORT------------------| |
|------------------------OK---------------------->| |
| |<-HANDSHAKE-|-HANDSHAKE->| |
| | |----------HANDSHAK---->|
|<---CONNECT/FIND(Leave Swarm x)-----| |
|<---CONNECT/FIND(Join Swarm y,z)----| |
Figure 1 Procedures of PPSP System
Zhang, et al. Expires January 1, 2015 [Page 5]
Internet-Draft Usage of PPSP July 2014
Peer C (Peer D): A peer that wants to join swarm x to obtain the
content provided by Peer A. And it has finished part of the content
transmission. (PeerMode is of Leech)
Assume that Peer A (Seeder) who wants to share a static/dynamic video
content with other peers. Firstly, Peer A MUST send a CONNECT message
to a tracker to start/join swarm x.
After received a correct CONNECT message, the tracker responses to
Peer A with an OK message.
In order to stay in swarm x, Peer A should send the STAT_REPORT
message to the tracker periodically. Normally, 3 minutes are
recommended for setting the value of Track_timeout (More details
described in section 4). An OK message should be generated and sent
back to Peer A whenever STAT_REPORT message reaches to the tracker.
Assume that Peer B (Leecher) wants to watch this video content
provided by Peer A. For that purpose, the Peer B needs to connect and
login a service Portal with peer ID and transaction ID to get the MPD
file of the selected swarm x. The MPD includes the IP address(es) of
tracker(s) and swarm x's ID.
Then Peer B starts to communicate with the tracker and join the swarm
x by sending a CONNECT message to the tracker. Such behavior will
trigger the tracker to send response back to Peer B with an
OK+PeerList message if previous check was correct. The message gives
Peer B a proper list including peers' name and IP addresses (only
Peer A and its address here).
Until now, Peer B knows which peer (Peer A here) has been in the
swarm x already. It sends a datagram including HANDSHAKE message to
Peer A (Due to there is only one seeder in the swarm x). The payload
of the HANDSHAKE message is a channel ID and a sequence of protocol
options.
Then Peer A decides whether it is willing to communicate with Peer B
based on the consideration of its status and current network
capacities. Once Peer A decides to respond, it returns a datagram
containing HANDSHAKE+HAVE message to Peer B. (HS is the abbreviation
of HANDSHAKE in Figure 1)
After acquiring the acknowledgement of Peer A, Peer B could use
another way (sending PER_REQ message to Peer A) to update PeerList.
This message could help Peer B to discover other new peers, which
could not be provided by the tracker.
Zhang, et al. Expires January 1, 2015 [Page 6]
Internet-Draft Usage of PPSP July 2014
Peer A returns a datagram with PER_RES message. Assume that
information of Peer C and D is included in it.
As the same rules mentioned before, if Peer B wants to initial a new
conversation with Peer C or D, it MUST send a datagram containing
HANDSHAKE message.
Similar with the situation of Peer A, Peer C or D needs to decide
whether it wants to respond to Peer B. Assume that Peer C is willing
to communicate with Peer B. Thus, it sends a datagram containing
HANDSHAKE+HAVE message. If Peer D wants to deny Peer B, it MUST send
a datagram including the HANDSHAKE+HAVE+CHOKE message.
Once receiving previous datagram, Peer B checks the messages and
knows who is available for communicating with. Then it can send
datagrams containing the REQUEST message to Peer A and C for asking
the chunks.
After Peer A or C receives the Peer B's request, it SHOULD send the
real data to Peer B. The datagram content depends on the video type:
INTEGRITY+DATA message for static video and SIGNED_INTEGRITY+DATA
message for dynamic video.
Upon receiving the corresponding data, Peer B sends back a datagram
including an ACK message to Peer A and C. Peer B SHOULD also send a
datagram containing HAVE message to all other peers that in the swarm
x for announcement purpose. The timing of sending HAVE message
depends on Peer B.
For avoiding timeout of track timer, Peer B MUST send STAT_REPORT
message to the tracker. Such report is confirmed when the tracker's
OK message reaches to Peer B.
For demonstrating all the functionalities, Peer D is supposed to
release previous rejection for Peer B by sending an UNCHOKE message.
Then, Peer B can send a new REQUEST message to Peer D.
Peer D responses with the actually data message. After content
integrity verification, Peer B MAY send HAVE message to other peers
in swarm x.
Peer C and D can also ask Peer B for chunks by sending REQUEST
message. Corresponding chunks should be sent if Peer B would like to
share.
Zhang, et al. Expires January 1, 2015 [Page 7]
Internet-Draft Usage of PPSP July 2014
If the above peers want to stay in the swarm, they need to send the
STAT_REPORT message to the tracker periodically, while sending the
KEEP_ALIVE message to other peers periodically.
After successfully received all the necessary content, Peer B can
close the connection by sending a HANDSHAKE message to all peers in
swarm x. An all 0-zeros channel ID MUST be embedded in HANDSHAKE
message. Meanwhile, Peer B SHOULD use FIND or CONNECT message to log
out and eliminate its state machine in tracker.
Peer B MAY use FIND or CONNECT message to join a new swarm, such as
swarm y or z in Figure 1. Similar instruction mentioned before can be
utilized for data exchanging.
Useful Message List:
CONNECT message
This message is used to register/leave a PPSP system and request
swarm actions with tracker.
FIND message
This message is used to request a new peer list to tracker whenever
needed. It is also used when a peer wants to leave the PPSP system
with tracker.
STAT_REPORT message
This message is used to send status and statistic data to tracker, in
order to facilitate the tracker service. This message MUST be
periodically sent while the peer is active.
OK message
This message is used for tracker to convey that has successfully
received the last message.
OK+PeerList message
This message is used for tracker to respond proper PeerList to peer.
HANDSHAKE message
This message MUST be sent as the first message in the first datagram
between peers, in order to start communication between peers.
Zhang, et al. Expires January 1, 2015 [Page 8]
Internet-Draft Usage of PPSP July 2014
HAVE message
This message is used to convey which chunks a peer has available for
download.
DATA message
This message is used to transfer chunks of content.
ACK message
This message is used to acknowledge received chunks after receiving a
DATA message.
REQUEST message
This message is used to request one or more chunks from another peer.
INTEGRITY message
This message carries information required by the receiver to verify
the integrity of a chunk. It is usually used in static content.
SIGNED_INTEGRITY message
This message is used to verify chunks in live streaming.
CHOKE message
The message is used to inform another peer that it will no longer
respond to any REQUEST massages from that peer.
UNCHOKE message
This message is used to inform another peer that it will respond to
new REQUEST messages from that peer again.
PER_REQ & PER_RES messages
These message allows peers to exchange the transport addresses of the
peers they are currently interacting with, thereby reducing the need
to contact a central tracker.
KEEPALIVE message
This message SHOULD be sent periodically to each peer it wants to
interact with in the future.
Zhang, et al. Expires January 1, 2015 [Page 9]
Internet-Draft Usage of PPSP July 2014
4. Suggestions for Parameters Setting in PPSP System
In the procedure of constructing the PPSP system, parameters setting
are quite important. This section will discuss related issues in
tracker protocol and peer protocol. The default values are provided
here as references. The practical setting can be adjusted according
to the different scenarios.
4.1. Parameters Setting in Tracker Protocol
Table 1 shows parameters, their default values and description in the
PPSP tracker protocol.
+--------------------+------------+-------------------------------+
| Name | Default | Description |
+--------------------+------------+-------------------------------+
| Init_timeout | 30 seconds | Maximum value of the "init |
| | | timer" used in the "per peer |
| | | transaction state machine" |
| Track_timeout | 3 minutes | Maximum value of the "track |
| | | timer" used in the "per peer |
| | | transaction state machine" |
| STAT_REPORT Period | 3 minutes | Maximum period of STAT_REPORT |
| | | message |
| Retry_timeout | 3 minutes | Maximum waiting time until a |
| | | peer initiates a retry process|
| ConcurrentLinks | NORMAL | Concurrent connectivity level |
| | | of peers, HIGH, LOW or NORMAL |
| OnlineTime | NORMAL | Availability or online |
| | | duration of peers, HIGH or |
| | | NORMAL |
| UploadBWlevel | NORMAL | Upload bandwidth capability |
| | | of peers, HIGH OR NORMAL |
+--------------------+------------+-------------------------------+
Table 1 PPSP Tracker Protocol Defaults
4.2. Parameters Setting in Peer Protocol
Since the PPSP peer protocol has a detailed description about
parameters, this section only adopt it as a reference to summarize
the table 2, which shows the parameters, their default value and
description.
Zhang, et al. Expires January 1, 2015 [Page 10]
Internet-Draft Usage of PPSP July 2014
+---------------------+-------------+-----------------------------+
| Name | Default | Description |
+---------------------+-------------+-----------------------------+
| Chunk Size | var | (Maximum) Size of a chunk |
| | 1024 bytes | |
| | recommended | |
| Static Content | 1 (Merkle | Methods for protecting the |
| Integrity Protection| Hash Tree) | integrity of static content |
| Method | | |
| Live Content | 3 (Unified | Methods for protecting the |
| Integrity Protection| Merkle Tree | integrity of static content |
| Method | | including "sign all" and |
| | | "Unified Merkle Tree" |
| Merkle Hash Tree | 0 (SHA1) | Hash function used for the |
| Function | | Merkle Hash Tree |
| Live Signature | 13 (ECDSAP2 | Must be defined for live |
| Algorithm | 56SHA256 | streaming |
| Chunk Addressing | 2 (32-bit | Methods of chunk addressing |
| Method | chunk | |
| | ranges) | |
| Live Discard Window | var | Must be defined for live |
| | | streaming |
| NCHUNKS_PER_SIG | var | Must be defined in the |
| | | Signed Munro Hash |
| Dead peer detection | No reply in | Guideline for declaring a |
| | 3 minutes + | peer is dead |
| | 3 datagrams | |
| KEEPALIVE Period | 2 minutes | Maximum period for a peer |
| | | to send KEEPALIVE datagram |
| | | to other peers |
+---------------------+-------------+-----------------------------+
Table 2 PPSP Peer Protocol Defaults
5. Limitations and Gaps Analysis
This section is to identify the limitations and gaps for the current
PPSP system from the standpoint of satisfying PPSP requirements.
1. According to Problem Statement and Requirements of PPSP [RFC6972],
the tracker protocol must be light weight, since a tracker may
need to serve a large number of peers. However, the function of
the FIND message is quite similar with the CONNECT message, due to
the same C-like syntax mentioned in the tracker protocol. The
necessity of having both messages in PPSP system should be further
discussed.
Zhang, et al. Expires January 1, 2015 [Page 11]
Internet-Draft Usage of PPSP July 2014
2. One target of PPSP is extending current Peer-to-Peer (P2P) system
in mobile and wireless environments [RFC6972]. However, the
message used in PPSP system does not contain related information
such as the packet loss rate and battery status, which is
essential for wireless and mobile environments.
3. The PPSP system provides two ways to fetch the PeerList. Peers can
obtain the PeerList from the tracker or they can get it through
the PER_REQ and PER_RES messages. When both methods are available,
how to update the local PeerList efficiently is still not clear.
4. The STAT_REPORT message of tracker protocol does not support the
exchanges of content data information, like chunkmaps, between an
active peer and a tracker. Thus, whenever a new peer wants to join
a swarm, the relevant tracker could only use PeerMode to choose
the PeerList and return to the new peer. In some cases there may
be only one seeding peer, while several peers that already
finished part of the content transmission and are willing to share
with others. As a result, the tracker could not provide the high
quality PeerList but just one seeder. Thus, the peer could only
rely on using the PEX-REQ message to update PeerList.
5. A peer may have the requirement to start streaming the content
from some specific point of the content timeline. For example, the
end user may watch only part of content and leave. When the end
user decides to resume the session he/she expects to continue
watching the intent from the point where he/she interrupted. The
peer may then request the tracker to select a subset of peers
capable to provide that specific content scope.
6. When a peer finishes the data transmission and gets the whole
content, the PPSP system does not allow it to change its PeerMode.
It is because peer cannot change it through STAT REPORT message.
6. Security Considerations
This document does not contain any security considerations.
7. IANA Considerations
There are presently no IANA considerations with this document.
Zhang, et al. Expires January 1, 2015 [Page 12]
Internet-Draft Usage of PPSP July 2014
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-ppsp-peer-protocol] Bakker, A., Petrocco, R., and V.
Grishchenko, "Peer-to-Peer Streaming Peer protocol
(PPSPP)", draft-ietf-ppsp-peer-protocol-10 (work in
progress), June 2014.
[I-D.ietf-ppsp-base-tracker-protocol] Cruz, R., Nunes, M., Gu, Y.,
Xia, J., and J. Taveira, "PPSP Tracker Protocol-Base
Protocol (PPSP-TP/1.0)", draft-ietf-ppsp-base-tracker-
protocol-03 (work in progress), December 2013.
[RFC6972] Zhang, Y. and N. Zong, "Problem Statement and Requirements
of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972,
July 2013.
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Hongke Zhang
Beijing Jiaotong University (BJTU)
Beijing, 100044, P.R.China
Email: hkzhang@bjtu.edu.cn
Di Wu
Beijing Jiaotong University (BJTU)
Beijing, 100044, P.R.China
Email: diwu2@seas.upenn.edu
Zhang, et al. Expires January 1, 2015 [Page 13]
Internet-Draft Usage of PPSP July 2014
Mi Zhang
Beijing Jiaotong University (BJTU)
Beijing, 100044, P.R.China
Email: 13120174@bjtu.edu.cn
Fei Song
Beijing Jiaotong University (BJTU)
Beijing, 100044, P.R.China
Email: fsong@bjtu.edu.cn
Zhang, et al. Expires January 1, 2015 [Page 14]