Internet DRAFT - draft-zhang-ppsp-usage
draft-zhang-ppsp-usage
PPSP Hongke Zhang
Internet Draft Fei song
Intended status: Informational Di Wu
Expires: September 4 2018 Mi Zhang
Tianming Zhao
Beijing Jiaotong University
March 2 2018
Usage of the Peer-to-Peer Streaming Protocol (PPSP)
draft-zhang-ppsp-usage-08.txt
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 September 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
(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.
Zhang, et al. Expires September 2, 2018 [Page 1]
Internet-Draft Usage of PPSP March 2018
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.
Table of Contents
1. Introduction ................................................ 2
2. Tetminology ................................................. 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 ............ 8
4.1. Parameters Setting in Tracker protocol .................. 9
4.2. Parameters Setting in Peer protocol ..................... 9
5. Limitations and Gaps Analysis ................................ 9
6. Security Consideration ...................................... 10
7. IANA Considerations ........................................ 10
8. References ................................................. 10
8.1. Normative References ................................... 10
8.2. Informative References ................................. 10
9. Acknowledgements ........................................... 10
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, it's unnecessary for end user 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 is proposed 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
Zhang, et al. Expires September 2, 2018 [Page 2]
Internet-Draft Usage of PPSP March 2018
media data directly among the peers. It currently runs on the top of
UDP using LEDBAT for congestion control.
This document includes several important operation issues in PPSP
usage, considering two basic modes: Leech mode and Seed mode. In
addition, the related parameters setting for default PPSP scenario
are given by the tracker protocol and peer protocol respectively.
The limitations and gaps of current PPSP system are identified by
the standpoint of satisfying PPSP requirements.
2. Tetminology
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
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, which
is different with previous protocol-related drafts. The following
section will provide both macroscopic overview and detailed steps.
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 is defined as 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. There are two different modes (Leech mode and Seed
Zhang, et al. Expires September 2, 2018 [Page 3]
Internet-Draft Usage of PPSP March 2018
mode) in PPSP based on the properties of peers. 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 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 VoD
streaming and live should be distinguished by the portal and
then the portal should select the appropriate tracker for peers.
3.2. Operation Illustration
Figure 1 illustrates the normal operation process of the PPSP system.
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
Zhang, et al. Expires September 2, 2018 [Page 4]
Internet-Draft Usage of PPSP March 2018
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 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. If the
previous check was correct, the tracker is triggered to send
response back to Peer B with an OK+PeerList message. Peer B is
offered a proper list including peers' name and IP addresses (only
Peer A and its address here) by the mentioned message.
Till now, Peer B realizes which peer (Peer A here) has already been
in the swarm x. And then it sends a datagram with HANDSHAKE message
to Peer A (Due to there is only a seeder in the swarm x). A channel
ID and a sequence of protocol options are the payload of HANDSHAKE
message.
Then Peer A determines whether to communicate with Peer B based on
considering the status and current network capacities. Once Peer A
decides to make response, it returns a datagram wit HANDSHAKE+HAVE
message to Peer B. (HS is the abbreviation of HANDSHAKE in Figure 1)
Peer B updates PeerList as OPTIONAL through another way after
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.
Peer B checks the messages and obtains which is available for
communication once receiving previous datagram. Then datagrams
Zhang, et al. Expires September 2, 2018 [Page 5]
Internet-Draft Usage of PPSP March 2018
containing the REQUEST message to Peer A and C asking for chunks is
send by Peer B.
After Peer A or C receives the Peer B's request, they SHOULD
send the datagrams 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.
+-------+ +------+ +------+ +------+ +------+ +------+
|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
According to the corresponding data received, Peer B replies a
datagram 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 demonstrate 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. Peer B MAY send
HAVE message to other peers in swarm x after the content
integrality is verified.
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.
Zhang, et al. Expires September 2, 2018 [Page 6]
Internet-Draft Usage of PPSP March 2018
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 be capitalized on 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 attends 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.
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
Zhang, et al. Expires September 2, 2018 [Page 7]
Internet-Draft Usage of PPSP March 2018
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.
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.
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.
Zhang, et al. Expires September 2, 2018 [Page 8]
Internet-Draft Usage of PPSP March 2018
4.1. Parameters Setting in Tracker protocol
Parameters, their default values and description in the PPSP tracker
protocol is shown in Table 1.
+--------------------+------------+------------------------------+
| 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 having 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.
+---------------------+-------------+-----------------------------+
| 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 related information such as the packet loss rate and battery
status is not included in the message used in PPSP system, 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. It is not definite to
update the local PeerList efficiently, when both methods are
available
3. It not supported by the STAT REPORT message of tracker protocol
to exchange the content data information between an active peer
and a tracker. Thus, the relevant tracker could only employ
PeerMode to choose the PeerList and return the new peer, whenever
a new peer wants to join a swarm. 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.
Zhang, et al. Expires September 2, 2018 [Page 9]
Internet-Draft Usage of PPSP March 2018
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. It is better to add some controllable limits
in the protocol, rather than limiting the download links through
ISPs or government
5. PT (private tracker) has become popular in recent years for
safety and manageability reasons. 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.
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. Acknowledgements
This document was prepared using 2-Word-v2.0.template.dot.
Zhang, et al. Expires September 2, 2018 [Page 10]
Internet-Draft Usage of PPSP March 2018
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
Tianming Zhao
Beijing Jiaotong University (BJTU)
Beijing, 100044, P.R.China
Email: 14125070@bjtu.edu.cn
Zhang, et al. Expires September 2, 2018 [Page 11]
