Usage of the Peer-to-Peer Streaming Protocol (PPSP)
draft-zhang-ppsp-usage-07
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 , Fei Song , Di Wu , Mi Zhang , Tianming Zhao | ||
| Last updated | 2017-09-02 | ||
| 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-07
PPSP Hongke Zhang
Internet Draft Fei Song
Intended status: Informational Di Wu
Expires: March 4 2018 Mi Zhang
Tianming Zhao
Beijing Jiaotong University
September 3, 2017
Usage of the Peer-to-Peer Streaming Protocol (PPSP)
draft-zhang-ppsp-usage-07.txt
Abstract
This document concerns several significant operation issues of Peer-
to-Peer Streaming Protocol (PPSP) usage, focusing on two basic modes:
Leech mode and Seed mode. The related parameters setting for default
PPSP scenario reference to tracker protocol and peer protocol
respectively. Besides, the limitations and gaps of current PPSP
system are identified at with 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 March 4, 2018.
Copyright Notice
Copyright (c) 2016 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
Zhang, et al. Expires March 4, 2018 [Page 1]
Internet-Draft Usatg of PPSP September 2017
(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
2. Terminology ................................................. 3
3. Operation of PPSP System ..................................... 3
3.1. Operation Overview ...................................... 3
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 .................... 11
5. Limitations and Gaps Analysis ............................... 12
6. Security Consideration ...................................... 13
7. IANA Considerations ........................................ 13
8. References ................................................. 13
8.1. Normative References ................................... 13
8.2. Informative References ................................. 14
9. Acknowledgments ............................................ 14
1. Introduction
The Peer-to-Peer Streaming Protocol (PPSP) supports two kinds of
streaming which include live and Video on Demand (VoD). It is
constitutive of two basic protocols: the PPSP peer protocol [RFC7574]
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, the end users are unnecessary to understand the
whole procedure works and the parameters setting when combining
above two mentioned protocol together in application. What's more,
the potential limitations of current protocol should also be learnt
and known to the community.
The tracker protocol which in a request/response model 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 advertising and exchange of media data
directly among the peers. It currently runs on the top of UDP using
LEDBAT for congestion control.
Zhang, et al. Expires March 4, 2018 [Page 2]
Internet-Draft Usatg of PPSP September 2017
This document includes several important operation issues in PPSP
usage, considering two basic modes: Leech mode and Seed mode. In
addition, the tracker protocol and peer protocol respectively give
the related parameters setting for default PPSP scenario. The
standpoint of satisfying PPSP requirements identifies the limitations
and gaps of current PPSP system.
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
[RFC7574] and PPSP-TP/1.0 [I-D.ietf-ppsp-base-tracker-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 associate
multiple entities working together, such as peers, trackers, portals,
etc., and achieve corresponding functions. Both macroscopic overview
and detailed steps are provided in the following sections.
3.1. Operation Overview
The PPSP supports two kinds of modes including real-time and VoD
streaming modes which involve two protocols: the PPSP tracker
protocol and the PPSP peer protocol.
The tracker refers to a directory service that maintains a list of
active peers participating in a specific audio/video channel or in
the distribution of a streaming file. It is a logical entity, which
can be centralized or distributed, and in this document, it is
treated as a single logical entity.
The peer refers to a participant in a P2P streaming system that both
receives streaming content and caches streaming content to other
participants. Based on the properties of peers, there are two
different modes (Leech mode and Seed mode) in PPSP. It will be
detailed in Section 3.2.
The basic communication unit of PPSP is message. In peer protocol,
multiple messages are typically multiplexed into a single datagram in
Zhang, et al. Expires March 4, 2018 [Page 3]
Internet-Draft Usatg of PPSP September 2017
transmission process. And in the PPSP system, there are several rules
MUST be obeyed.
1. In the same swarm, the same chunk addressing method MUST be used
to ensure that peers can communicate with each other smoothly.
2. The portal needs to pick an appropriate tracker supporting the
same encoding type as the peer. Additionally, the portal needs to
distinguish the VoD streaming from live streaming and then selects
the app ropriate tracker for peers.
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)
Peer C (Peer D): A peer that obtain the content provided by Peer A
through joining swarm x. And it has finished part of the content
transmission. (PeerMode is of Leech)
Assume that Peer A (Seeder) attends 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 a correct CONNECT message is received, the tracker responses to
Peer A with an OK message.
In order to keep in swarm x, Peer A should send the STAT_REPORT
message to the tracker periodically. Normally, it is recommended 3
minutes 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 the tracker.
Assume that Peer B (Leecher) attends to watch this video content
provided by Peer A. Hence, Peer B need connect and login in a service
Zhang, et al. Expires March 4, 2018 [Page 4]
Internet-Draft Usatg of PPSP September 2017
Portal with its peer ID to get the MPD file, includes the IP
address(es) of tracker(s) and swarm x's ID of the selected swarm x.
Then Peer B starts to communicate with the tracker and try to join
the swarm x by sending a CONNECT message to the tracker. This will
trigger the tracker to send response back to Peer B with an
OK+PeerList message if previous check was correct. The message
provides Peer B a proper list including peers' name and IP addresses
(only Peer A and its address here).
Till now, Peer B realizes which peer (Peer A here) has already been
in the swarm x. It sends a datagram with HANDSHAKE message to Peer A
(Due to there is only a seeder in the swarm x). The payload of the
HANDSHAKE message is a channel ID and a sequence of protocol options.
Then Peer A determines whether to communicate with Peer B base on
considering the status and current network capacities. Once Peer A
decides to make respondence, it returns a datagram wit HANDSHAKE+HAVE
message to Peer B.(HS is the abbreviation of HANDSHAKE in Figure 1)
Then Peer A determines whether to communicate with Peer B base on
considering the status and current network capacities. Once Peer A
decides to make respondence, it returns a datagram wit HANDSHAKE+HAVE
message to Peer B.(HS is the abbreviation of HANDSHAKE in Figure 1)
After acquiring the acknowledgement of Peer A, Peer B updates
PeerList as OPTIONAL through another way (sending PEX_REQ message to
Peer A). The message will help Peer B to discover other new peers,
which could not be provided by the tracker.
Peer A returns a datagram with PEX_RES message. Assume it including
the information of Peer C and Peer D.
As mentioned before, if Peer B attends to initial a new conversation
with Peer C or D, it MUST send a datagram including HANDSHAKE message.
Similar with Peer A, Peer C or D needs to decide whether it will
reply Peer B or not. If Peer C is willing to contact with Peer B. It
responds a datagram containing HANDSHAKE+HAVE message. If Peer D
attends to deny Peer B, it MUST reply a datagram including the
HANDSHAKE+HAVE+CHOKE message.
Once receiving previous datagram, Peer B checks the messages and
obtains which is available for communidation. Then it sends datagrams
containing the REQUEST message to Peer A and C asking for chunks.
Zhang, et al. Expires March 4, 2018 [Page 5]
Internet-Draft Usatg of PPSP September 2017
After Peer A or C receives the Peer B's request, it SHOULD send the
datagram to Peer B. The content of datagram depends on the video type:
INTEGRITY+DATA message for static video and SIGNED_INTEGRITY+DATA
message for dynamic video.
Zhang, et al. Expires March 4, 2018 [Page 6]
Internet-Draft Usatg of PPSP September 2017
+-------+ +------+ +------+ +------+ +------+ +------+
|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-->| | |
| |<-PEX_REQ---| | |
| |--PEX_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)----| |
Procedures of PPSP System
Zhang, et al. Expires March 4, 2018 [Page 7]
Internet-Draft Usatg of PPSP September 2017
According to the corresponding data received, Peer B replies
adatagram Containing an ACK message to Peer A and C. Peer B SHOULD
also send a datagram containing HAVE message to all other peers in
the swarm x for announcement purpose. The timing of sending HAVE
message depends on Peer B.
In order to 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 replies with the actually data message. After the content
integrality is verified, Peer B MAY send HAVE message to other peers
in swarm x.
Peer C and D can also require the Peer B chunks by sending REQUEST
message. Whether the corresponding chunks could be sent or not
depends on Peer B.
If the above peers attend to keep in the swarm, they need to send the
STAT_REPORT message to the tracker while send the KEEP_ALIVE message
to other peers periodically.
After all the necessary content is received successfully, 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 send STAT_REPORT or CONNECT message
to log out and eliminate its state in tracker.
Peer B MAY employ CONNECT message to join a new swarm, such as swarm
y or z in Figure 1. Similar instruction mentioned before can
becapitalized on data exchanging.
Useful Message List:
o CONNECT message
This message is used to register/leave a PPSP system and request
swarm actions with tracker.
o FIND message
This message is used to request a new peer list to tracker whenever
needed. It is also used when a peer attends to leave the PPSP system
with tracker.
Zhang, et al. Expires March 4, 2018 [Page 8]
Internet-Draft Usatg of PPSP September 2017
o 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.
o OK message
This message is used for tracker to convey that has successfully
received the last message.
o OK+PeerList message
This message is used for tracker to respond proper PeerList to peer.
o HANDSHAKE message
This message MUST be sent as the first message in the first datagram
between peers, in order to start communication between peers.
o HAVE message
This message is used to convey which chunks a peer has available for
download.
o DATA message
This message is used to transfer chunks of content.
o ACK message
This message is used to acknowledge received chunks after receiving a
DATA message.
o REQUEST message
This message is used to request one or more chunks from another peer.
o INTEGRITY message
This message carries information required by the receiver to verify
the integrity of a chunk. It is usually used in static content.
o SIGNED_INTEGRITY message
This message is used to verify chunks in live streaming.
Zhang, et al. Expires March 4, 2018 [Page 9]
Internet-Draft Usatg of PPSP September 2017
o CHOKE message
The message is used to inform another peer that it will no longer
respond to any REQUEST massages from that peer.
o UNCHOKE message
This message is used to inform another peer that it will respond to
new REQUEST messages from that peer again.
o PEX_REQ & PEX_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.
o KEEPALIVE message
This message SHOULD be sent periodically to each peer it wants to
interact with in the future.
4. Suggestions for Parameters Setting in PPSP System
In the procedure of constructing the PPSP system, parameters setting
is absolutely crucial. This section will discuss related issues in
tracker protocol and peer protocol. The default values are provided
as references. The practical setting can be adjusted according to
different scenarios
4.1. Parameters Setting in Tracker Protocol
Table 1 shows parameters, their default values and description in the
PPSP tracker protocol.
Zhang, et al. Expires March 4, 2018 [Page 10]
Internet-Draft Usatg of PPSP September 2017
+--------------------+------------+------------------------------+
| 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
For the PPSP peer protocol has a detailed description about
parameters, this section only assume it as a reference to summarize
Table 2, which reveals some of the parameters default values and
descriptions. Some parameters should be recommended as a fixed value
while others should alter according to users' demands or network
conditions.
Zhang, et al. Expires March 4, 2018 [Page 11]
Internet-Draft Usatg of PPSP September 2017
+---------------------+-------------+-----------------------------+
| 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 aims to identify the limitations and gaps of the current
PPSP system from the standpoint of satisfying PPSP requirements.
1. One of the PPSP target is extending current Peer-to-Peer (P2P)
system in mobile and wireless environments [RFC6972]. However, the
message used in PPSP system does not include related information
such as the packet loss rate and battery status, which is
essential for wireless and mobile environments.
2. The PPSP system provides two ways to acquire the PeerList. Peer
can obtain the PeerList from the tracker or they can get it
through the PEX_REQ and PEX_RES messages. When both methods are
Zhang, et al. Expires March 4, 2018 [Page 12]
Internet-Draft Usatg of PPSP September 2017
available, it is not definite to update the local PeerList
efficiently.
3. The STAT_REPORT message of tracker protocol does not support
exchange the content data information between an active peer and a
tracker. Thus, whenever a new peer wants to join a swarm, the
relevant tracker could only employ PeerMode to choose the PeerList
and return the new peer. In the cases which there is only one
seeding peer while other peers that already finished part of the
content transmission and are willing to share with others.
Therefore, the tracker could not provide the high quality PeerList
but just a seeder. Thus, the peer could only update PeerList
relying on the PEX-REQ message.
4. In some cases, the user may want to adjust the video definition
based on the bandwidth (or user demand) automatically (or
manually). Or the user may watch videos and play online games at
the same time, and he/she doesn't want the videos occupy too much
of the bandwidths. This will need adaptive multi-rate control for
both users and ISPs. Rather than limiting the download links
throuth ISPs or government, it is better to add some controllable
limits in the protocol.
5. For safety and manageability reasons, PT (private tracker) has
become popular in recent years. It is uncertain whether this
should be taken into consideration in PPSP. If the answer is
positive, the tracker protocol should make some changes in finding
& connecting private tracker and add data traffic statistics part.
6. Security Consideration
This document does not contain any security considerations.
7. IANA Considerations
There are presently no IANA considerations with this document.
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.
Zhang, et al. Expires March 4, 2018 [Page 13]
Internet-Draft Usatg of PPSP September 2017
8.2. Informative References
[RFC7574] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to-
Peer Streaming Peer protocol (PPSPP)", RFC 7574, October 2015.
[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-12 (work in progress),
January 2016.
[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
Fei Song
Beijing Jiaotong University (BJTU)
Beijing, 100044, P.R.China
Email: fsong@bjtu.edu.cn
Di Wu
Beijing Jiaotong University (BJTU)
Beijing, 100044, P.R.China
Email: diwu2@seas.upenn.edu
Mi Zhang
Beijing Jiaotong University (BJTU)
Beijing, 100044, P.R.China
Email: 13120174@bjtu.edu.cn
Zhang, et al. Expires March 4, 2018 [Page 14]
Internet-Draft Usatg of PPSP September 2017
Tianming Zhao
Beijing Jiaotong University (BJTU)
Beijing, 100044, P.R.China
Email: 14125070@bjtu.edu.cn
Zhang, et al. Expires March 4, 2018 [Page 15]