PPSP Rui S. Cruz
INTERNET-DRAFT Mario S. Nunes
Intended Status: Standards Track IST/INESC-ID/INOV
Expires: May 2, 2012 Yingjie Gu
Jinwei Xia
Huawei
David A. Bryan
Polycom
Joao P. Taveira
IST/INOV
Deng Lingli
China Mobile
October 30, 2011
PPSP Tracker Protocol
draft-gu-ppsp-tracker-protocol-06
Abstract
This document outlines the functionality required for an HTTP-based
P2P Streaming Tracker Protocol, including requirements, functional
entities and architecture, components, message flows, with detailed
message processing instructions using an HTTP/XML encoding, the
respective parameters, methods, and message formats, formal syntax
and semantics. The PPSP Tracker Protocol proposed in this document
extends the capabilities of PPSP to support adaptive and scalable
video and 3D video, for Video On Demand (VoD) and Live video
services. The Tracker Protocol is an application-level protocol for
peers to publish/request content, provide peer lists to peers and
peer status to Trackers.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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."
Gu, et al. Expires May 2, 2012 [Page 1]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Protocol Request Messages . . . . . . . . . . . . . . . . . 10
3.2 Protocol Response Messages . . . . . . . . . . . . . . . . . 11
3.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 Streaming Modes . . . . . . . . . . . . . . . . . . . . . . 14
3.6 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . 14
3.7 Media Presentation Description (MPD) . . . . . . . . . . . . 14
4 Messages syntax and processing . . . . . . . . . . . . . . . . . 17
4.1 HTTP/XML Encoding . . . . . . . . . . . . . . . . . . . . . 17
4.2 Method Fields . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Message Processing . . . . . . . . . . . . . . . . . . . . . 19
4.4 CONNECT Message . . . . . . . . . . . . . . . . . . . . . . 20
4.5 DISCONNECT message . . . . . . . . . . . . . . . . . . . . . 22
4.6 JOIN Message . . . . . . . . . . . . . . . . . . . . . . . . 23
4.7 LEAVE Message . . . . . . . . . . . . . . . . . . . . . . . 26
4.8 FIND Message . . . . . . . . . . . . . . . . . . . . . . . . 27
4.9 STAT_REPORT Message . . . . . . . . . . . . . . . . . . . . 29
4.10 KEEPALIVE Message . . . . . . . . . . . . . . . . . . . . . 31
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 32
Gu, et al. Expires May 2, 2012 [Page 2]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
5.1 Authentication between Tracker and Peers . . . . . . . . . . 32
5.2 Content Integrity protection against polluting
peers/trackers . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Residual attacks and mitigation . . . . . . . . . . . . . . 33
5.4 Pro-incentive parameter trustfulness . . . . . . . . . . . . 33
6 PPSP Requirements Compliance . . . . . . . . . . . . . . . . . . 34
6.1 PPSP Basic Requirements . . . . . . . . . . . . . . . . . . 34
6.2 PPSP Tracker Protocol Requirements . . . . . . . . . . . . . 35
6.3 PPSP Security Considerations . . . . . . . . . . . . . . . . 35
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 36
8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 36
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 37
9.2 Informative References . . . . . . . . . . . . . . . . . . . 37
Appendix A. PPSP Tracker Protocol XML-Schema . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Gu, et al. Expires May 2, 2012 [Page 3]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
1 Introduction
The P2P Streaming Protocol (PPSP) is composed of two protocols: the
PPSP Tracker Protocol and the PPSP Peer Protocol.
[I-D.ietf-ppsp-problem-statement] specifies that the Tracker Protocol
should standardize format/encoding of information and messages
between PPSP peers and PPSP trackers and [I-D.ietf-ppsp-reqs] defines
the requirements.
The PPSP Peer protocol controls the advertising and exchange of media
data directly between peers.
The PPSP Tracker Protocol provides communication between Trackers and
Peers, by which Peers exchange meta information with trackers, report
streaming status and request candidate lists from trackers.
The PPSP architecture requires PPSP peers able to communicate with a
Tracker in order to participate in a particular swarm. This
centralized Tracker service is used for peer and content registration
and location. Content indexes (Media Presentation Descriptions) are
also stored in the Tracker system allowing the association of content
location information to the active peers in the swarm sharing the
content.
The process used for media streaming distribution assumes a segment
transfer scheme whereby the original content (that can be encoded
using adaptive or scalable techniques) is chopped into small segments
(and subsegments) and has the following representations:
1. Adaptive - alternate representations with different qualities and
bitrates; a single represention is non-adaptive;
2. Scalable description levels - multiple additive descriptions
(i.e., addition of descriptions refine the quality of the video);
3. Scalable layered levels - nested dependent layers corresponding to
several hierarchical levels of quality, i.e., higher enhancement
layers refine the quality of the video of lower layers.
4. Scalable multiple views - views correspond to mono and
stereoscopic 3D videos, with several hierarchical levels of
quality.
These streaming distribution techniques support dynamic variations in
video streaming quality while ensuring support for a plethora of end
user devices and network connections.
The signaling and the media data transfer between PPSP peers is not
in the scope of this specification.
This documents describes the PPSP Tracker protocol and how it
Gu, et al. Expires May 2, 2012 [Page 4]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
satisfies the requirements for the IETF Peer-to-Peer Streaming
Protocol (PPSP), in order to derive the implications for the
standardization of the PPSP streaming protocols and to identify open
issues and promote further discussion. [I-D.ietf-ppsp-survey].
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].
This draft uses terms defined in [I-D.ietf-ppsp-problem-statement]
and in [I-D.xiao-ppsp-reload-distributed-tracker].
Absolute Time: Absolute time is expressed as ISO 8601 [ISO.8601.2004]
timestamps, using zero UTC offset (GMT). Fractions of a second may
be indicated. Example for December 25, 2010 at 14h56 and 20.25
seconds: basic format 20101225T145620.25Z or extended format
2010-12-25T14:56:20.25Z.
Adaptive Streaming: multiple alternate representations (different
qualities and bitrates) of the same media content co-exist for the
same streaming session; each alternate representation corresponds to
a different media quality level; peers can choose among the alternate
representations for decode and playback.
Base Layer: the playable representation level in Scalable Video
Coding (SVC) required by all upper level Enhancements Layers for
proper decoding of the video.
Chunk: A chunk is a generic term used whenever no ambiguity is
raised, to refer to a segment or a subsegment of partitioned
streaming media.
Complementary Representation: Representation in a set of
representations which have inter-representation dependencies and
which when combined result in a single representation for decoding
and presentation.
Connection Tracker: The Tracker Node to which the PPSP Peer will
connect when it wants to join the PPSP system.
Continuous media: Media with an inherent notion of time, for example,
speech, audio, video, timed text or timed metadata.
Enhancement Layer: enhancement differential quality level
(complementary representation) in Scalable Video Coding (SVC) used to
produce a higher quality, higher definition video in terms of space
Gu, et al. Expires May 2, 2012 [Page 5]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
(i.e., image resolution), time (i.e., frame rate) or Signal-to-Noise
Ratio (SNR) when combined with the playable Base Layer.
Join Time: Join time is the absolute time when a peer registers on a
Tracker. This value is recorded by the Tracker and is used to
calculate Online Time.
Live streaming: The scenario where all clients receive streaming
content for the same ongoing event. The lags between the play points
of the clients and that of the streaming source are small.
Media Component: An encoded version of one individual media type such
as audio, video or timed text with specific attributes, e.g.,
bandwidth, language, or resolution.
Media Presentation Description (MPD): Formalized description for a
media presentation, i.e., describes the structure of the media,
namely, the codecs used, the chunks, and the corresponding mapping
within a container file system.
Online Time: Online Time shows how long the peer has been in the P2P
streaming system since it joins. This value indicates the stability
of a peer, and it is calculated by Tracker when necessary.
Peer: A peer refers to a participant in a P2P streaming system that
not only receives streaming content, but also stores and uploads
streaming content to other participants.
PeerID: Unique identifier for the peer. The PeerID and any required
security certificates are obtained from an offline enrollment server.
Peer-Peer Messages (i.e., Peer Protocol): The Peer Protocol messages
enable each Peer to exchange content availability with other Peers
and request other Peers for content.
PPSP: The abbreviation of Peer-to-Peer Streaming Protocols. PPSP
protocols refer to the key signaling protocols among various P2P
streaming system components, including the tracker and peers.
Representation: Structured collection of one or more media
components.
Scalable Streaming: With Multiple Description Coding (MDC), multiple
additive descriptions (that can be independently played-out) to
refine the quality of the video when combined together. With Scalable
Video Coding (SVC), nested dependent enhancement layers (hierarchical
levels of quality), refine the quality of lower layers, from the
lowest level (the playable Base Layer). With Multiple View Coding
Gu, et al. Expires May 2, 2012 [Page 6]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
(MVC), multiple views allow the video to be played in 3D when the
views are combined together.
Segment: A segment is a resource that can be identified, by an ID or
an HTTP-URL and possibly a byte-range, and is included in the MPD.
The segment is a basic unit of partitioned streaming media, which is
used by a peer for the purpose of storage, advertisement and exchange
among peers.
Subsegment: Smallest unit within segments which may be indexed at the
segment level.
Swarm: A swarm refers to a group of clients (i.e., peers) sharing the
same content (e.g., video/audio program, digital file, etc.) at a
given time.
SwarmID: Unique identifier for a swarm. It is used to describe a
specific resource shared among peers.
Tracker: A tracker refers to a centralized logical directory service
used to communicate with PPSP Peers for content registration and
location, which maintains the lists of PPSP peers storing segments
for a specific live content channel or streaming file and answers
queries from PPSP peers.
Tracker-Peer Messages (i.e., Tracker Protocol): The Tracker Protocol
messages provide communication between Peers and Trackers, by which
Peers provide content availability, report streaming status and
request candidate Peer lists from Trackers.
Video-on-demand (VoD): A kind of application that allows users to
select and watch video content on demand.
3. Protocol Overview
The functional entities involved in the PPSP Tracker Protocol are
Trackers and Peers (which may support different capabilities).
Peers correspond to devices that actually participate in sharing a
media content and are organized in (various) swarms corresponding
each swarm to the group of peers streaming that content at any given
time. Each peer stores chunks of the media content, called segments
(or subsegments), and contacts the Tracker to advertise which
information it has available. When a peer wishes to obtain
information about the swarm, it contacts the Tracker to find other
peers participating in that specific swarm.
Gu, et al. Expires May 2, 2012 [Page 7]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
The Tracker is a logical entity that maintains the lists of peers
storing chunks for a specific Live media channel or media streaming
content, answers queries from peers and collects information on the
activity of peers. While a Tracker may have an underlying
implementation consisting of more than one physical node, logically
the Tracker can most simply be thought of as a single element, and in
this document, it will be treated as a single logical entity.
The Tracker Protocol is not used to exchange actual content data
(either VoD or Live streaming) with peers, but information about
which peers can provide which pieces of content.
A P2P streaming process is summarized in Figure 1.
When a peer wants to receive streaming of a selected content:
1. Peer connects to a local Connection Tracker and joins a swarm.
2. Peer acquires a list of peers from the Connection Tracker.
3. Peer exchanges its content availability with the peers on the
obtained peer list.
4. Peer identifies the peers with desired content.
5. Peer requests for the content from the identified peers.
When a peer wants to share streaming of certain content with others:
1. Peer connects to the Connection Tracker.
2. Peer sends information to the Connection Tracker about the swarm
it belongs to (joins), plus streaming status and/or content
availability.
+-----------------------------------+
| Tracker |
+-----------------------------------+
^ | ^
connect/ | | |
join/ | | peer list |streaming Status/
find/ | | |Content availability/
leave/ | | |node capability
disconnect | V |
+-------------+ +------------+
| Peer 1 |<------------->| Peer 2 |
+-------------+ content info/ +------------+
data requests
Figure 1: A PPSP streaming process
The PPSP Tracker Protocol is a request-response protocol. Requests
are sent, and responses returned to these requests. A single request
Gu, et al. Expires May 2, 2012 [Page 8]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
generates a single response (neglecting fragmentation of messages).
The specific operations of the protocol at present, are listed in
Table 1:
+---------------+
| PPSP Tracker |
| Req. Messages |
+---------------+
| CONNECT |
| DISCONNECT |
| JOIN |
| LEAVE |
| FIND |
| STAT_REPORT |
| KEEPALIVE |
+---------------+
Table 1: Request Messages
The data managed at the peer and the tracker correspond to status
information about the peer in each swarm, as illustrated in Figure 2.
Peer
+-------------------+
|Data management |
| SwarmID |
| - peer list |
| - Buffer map |
| |
+-------------------+
^
--------------*-----------
Tracker V
+---------------------------------------------------------+
| Data management on Tracker |
| |
| +======================+ +======================+ |
| |peer status | |content status | |
| | PeerID | | +----------------+ | |
| | - online time | | | SwarmID | | |
| | - peer property | | | - Chunk Map | | |
| | - link status | | | - peer list | | |
| | - etc. | | +----------------+ | |
| +======================+ +======================+ |
+---------------------------------------------------------+
Figure 2: PPSP Tracker Protocol data management components
Gu, et al. Expires May 2, 2012 [Page 9]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
3.1 Protocol Request Messages
CONNECT: This message is used when a Peer connects to the system. The
Tracker records the PeerID, connect-time (referenced to the absolute
time), peer IP addresses and link status. The method allows a
security layer to be negotiated in the authentication protocol
exchange between the Peer and the Tracker [RFC4422]. The security
layer provides data integrity, data confidentiality, and other
services. The security layer is installed by the Tracker after
indicating the outcome of the authentication exchange (an
authentication token) and installed by the peer upon receipt of the
outcome indication. In both cases, the layer is installed before
transfer of further protocol data. The security layer remains in
effect until either a subsequently negotiated security layer is
installed or the connection is closed (via DISCONNECT or after some
pre-configured time).
DISCONNECT: This message is used when the Peer intends to leave the
system and no longer participate in any swarm. The Tracker deletes
the corresponding activity records related to the Peer (including its
status and all content status for all swarms), optionally updating
the information on the historical profile record of that Peer.
JOIN: This message is used for a Peer to notify the Tracker that it
wish to participate in a particular swarm. The tracker records the
content availability, i.e., adds the Peer to the candidate peers list
for the swarm.
LEAVE: This message is used when a Peer wants to indicate to the
Tracker that it no longer wish to participate in a particular swarm.
The tracker will no longer provide this Peer information to others
when they request to join that swarm.
FIND: This message allows a Peer to request to the Tracker the peer
list for a specific content representation or specific chunks of a
media component in a swarm. On receiving a FIND message, the Tracker
finds the candidate peers listed in content status, and returns the
list to the requesting peer. To create the peer list, the Tracker may
take peer status, capabilities and peers priority into consideration
when selecting the candidate peers. Peer priority may be determined
by network topology preference, operator policy preference, etc.
STAT_REPORT: This message allows the exchange of statistic and status
data between an active Peer and a Tracker to improve system
performance. The method is initiated by the peer.
KEEPALIVE: These messages are periodically sent from a Peer to the
Tracker to notify it that the Peer is still alive, even if inactive,
Gu, et al. Expires May 2, 2012 [Page 10]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
preventing the Tracker from disconnecting the Peer after some pre-
configured time (assuming that the Peer is no longer available).
Timer on the tracker can be reset by any other message send from the
Peer.
3.2 Protocol Response Messages
The Response messages correspond to a number of logical responses
common to the Tracker or the Peer protocols request messages.
Incorrectly formatted request bodies are handled by the HTTP protocol
itself and reported in an HTTP message.
At present, the minimum set of response messages for the PPSP
Streaming Protocols is the following, re-using the error codes from
HTTP conveyed in the actual HTTP message:
SUCCESSFUL (200 OK): indicates that a message has been processed
properly and the desired operation has completed. If the message is a
request for information, the body of the message will also include
the requested information. The information returned in this message
body for each request message is the following:
JOIN, FIND, KEEPALIVE and STAT_REPORT: returns any required status
information about the successfully completed operation.
FIND: returns the list of peers meeting the desired criteria.
INVALID SYNTAX (400 Bad Request): Indicates an error in the format of
the message/message body. These responses correspond to errors within
the XML/PPSP protocol messages, not HTTP.
VERSION NOT SUPPORTED (400 Bad Request): Invalid version of the
protocol or message bodies. These responses correspond to errors
within the XML/PPSP protocol messages, not HTTP.
AUTHENTICATION REQUIRED (401 UNAUTHORISED): Authentication is
required to access this information.
MESSAGE FORBIDDEN (403 FORBIDDEN): The requester is not allowed to
make this request.
OBJECT NOT FOUND (404 NOT FOUND): The requested object or a swarm
that is being searched for cannot be found.
INTERNAL ERROR (500 INTERNAL SERVER ERROR): The server was unable to
process the request due to an internal error.
TEMPORARILY OVERLOADED (503 SERVICE UNAVAILABLE): The server is
Gu, et al. Expires May 2, 2012 [Page 11]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
unable to process this message at this time.
3.3 Assumptions
The functional entities related to PPSP protocols are the Client
Media Player, the service Portal, the Tracker and Peers. Their
complete description is not discussed in this document (as not in the
scope of this specification).
The Client Media Player is the entity providing a direct interface to
the end user at the client device, and includes the functions to
select, request, decode and render contents. In PPSP the Client Media
Player interfaces with the Peer using request and response standard
formats for HTTP Request and Response messages [RFC2616].
The service Portal is a logical entity typically used for client
enrollment and content information publishing, searching and
retrieval.
The Tracker is a logical entity that maintains the lists of PPSP
active peers storing and exchanging chunks for a specific media
content. The Tracker also stores the status of peers, to help in the
selection of appropriate candidate peers for a requesting peer. The
Tracker can be realized by geographically distributed tracker nodes
or multiple server nodes in a data center, increasing the content
availability, the service robustness and the network scalability or
reliability. The management and locating of content index information
are totally internal behaviors of the Tracker system, which is
invisible to the PPSP Peer
[I-D.xiao-ppsp-reload-distributed-tracker].
The Peer is also a logical entity embedding the P2P core engine, with
a client serving side interface (a proxy HTTP server) to respond to
Client Media Player requests and a network side interface to exchange
data and PPSP signaling with Peers and Trackers.
3.4 Bootstrapping
In order to join an existing P2P streaming service and to participate
in content sharing, any Peer must first locate a Tracker, using for
example, the following methods (as illustrated in Figure 3):
1. From a service provider provisioning mechanism: this is a typical
case used on the provider Super-Seeders (edge caches and/or Media
Servers).
2. From a web page: a Publishing and Searching Portal may provide
tracker location information to end users.
3. From the MPD file of a content: this metainfo file must contain
Gu, et al. Expires May 2, 2012 [Page 12]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
information about the address of one or more Connection Trackers
(that can be grouped by tiers of priority) which are controlling
the swarm for that media content.
In order to be able to bootstrap, a peer must first obtain a PeerID
(identity associated with the authentication credentials) and any
required security certificates from an enrollment service (user
registration).
+--------+ +--------+ +--------+ +---------+ +--------+
| Player | | Peer 1 | | Portal | | Tracker | | Peer 2 |
+--------+ +--------+ +--------+ +---------+ +--------+
| | | | |
|--Page request----------------->| | |
|<--------------Page with links--| | |
|--Select stream (MPD Request)-->| | |
|<-----------------------OK+MPD--| | |
|--MPD---------->|--CONNECT-------------------->| |
| |<---------------OK+AuthToken--| |
| |--JOIN----------------------->| |
|<-----------OK--|<----------------OK+Peerlist--| |
| |--GET_CHUNKMAP (Peer protocol)----------->|
| |<-------------------------------ChunkMap--|
|--GET (Chunk)-->|--GET_CHUNK (Peer protocol)-------------->|
|<-----OK+Chunk--|<----------------------------------Chunk--|
: : : : :
| |--FIND----------------------->| |
| |<----------------OK+Peerlist--| |
|--GET (Chunk)-->|--GET_CHUNK (Peer protocol)-------------->|
|<-----OK+Chunk--|<----------------------------------Chunk--|
: : : : :
| | | | |
| |--STAT_REPORT---------------->| |
| |<-------------------------Ok--| |
|--GET (Chunk)-->|--GET_CHUNK (Peer protocol)-------------->|
|<-----OK+Chunk--|<----------------------------------Chunk--|
: : : : :
| | | |
| |--KEEPALIVE------------------>| |
| |<-------------------------Ok--| |
: : : : :
| | | |
| |--LEAVE/DISCONNECT----------->| |
| |<-------------------------Ok--| |
Figure 3: A typical PPSP session
The specification of the mechanism used to obtain a PeerID and
Gu, et al. Expires May 2, 2012 [Page 13]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
certificates is not in the scope of this document.
3.5 Streaming Modes
The streaming technique is pull-based, i.e., the client peer requests
the media chunks from serving peers and is responsible for handling
the buffering that is necessary for the playback processes during the
download of the media chunks, turning this technique more robust to
peer churn but still with acceptable latency for a smooth play-out.
In Live streaming, all peers are interested in the media coming from
an ongoing program, which means that all peers share nearly the same
streaming content at a given point of time. Peers may store the live
media for further distribution (known as time-shift TV), where the
stored media is distributed in a VoD-like manner.
In VoD, different peers watch different parts of the recorded media
content during a past event. In this case, each peer keeps asking
other peers which media chunks are stored in which peers, and then
gets the required media from certain/selected peers. While watching
VoD, a peer can also switch to any place of the content, e.g., skip
the credits, or skip the part that is not interested in. In this case
the peer may not download and store all the content segments. From
the whole swarm point of view, the participating peers typically
store different parts of content.
3.6 NAT Traversal
It is assumed that all trackers must be in the public Internet and
have been placed there deliberately. This document will not describe
NAT Traversal mechanisms but the proposed protocol tries to enable
flexible NAT Traversal using ICE [RFC5245], considering that the
Tracker node provides NAT traversal services in PPSP (STUN-like
Tracker) by discovering the reflexive address of Peer via PPSP
Tracker Protocol messages, enabling it to put the address it observes
in CONNECT responses [I-D.li-ppsp-nat-traversal-02]. Future versions
will consider the requirements raised by NAT.
3.7 Media Presentation Description (MPD)
The MPD file describes a Media Presentation, i.e., a bounded or
unbounded presentation of media content. In particular, it defines
formats to announce resource identifiers for segments and subsegments
(layers in case of SVC, descriptions in case of MDC, or views in case
of 3D) and to provide the context for these identified resources
within a Media Presentation, i.e., describes the structure of the
media, the codecs used (as registered with the MP4 registration
authority [MP4-Reg]), the segments and the corresponding mapping
Gu, et al. Expires May 2, 2012 [Page 14]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
within a container file system.
The MPD contains information about the preferred Connection Trackers,
than can be classified in tiers of priority (attribute "tier").
The MPD is a Well-Formed XML Document, encoded as double-byte
Unicode. The XML-Schema of the MPD will in the future align with
ISO/IEC 23001-6 [ISO.IEC.23001-6].
123456abcd
path/name
some description
Figure 4: XML MPD for a VoD scalable video
The MPD is a composite schema that includes, as root Element, a
StreamInfo field that encapsulates all the metadata required for the
play-out of the media in groups of fields with
elements corresponding to each component of the media
(video, audio) streams, as well as other associated metadata
(subtitles, text descriptions, etc.). The different elements
may include specific descriptor elements, like Video and Audio and
respective attributes for each of the media types. An example of a
XML MPD for a VoD scalable video content is the following (Figure 4):
The MPD file for P2P Streaming MUST contain Tracker information prior
to its upload to the Tracker during the publishing procedure and can
be compressed with GZIP file format [RFC1952] in order to be used
with HTTP compression [RFC2616] for faster transmission times and
less network bandwidth usage.
Gu, et al. Expires May 2, 2012 [Page 15]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
The Client Media Player parses the downloaded MPD file and, if it
includes information for P2P Streaming, sends the file to the Peer
via a HTTP POST and waits for the response in order to start
requesting media chunks to decode and play-out.
The MPD file for Live Streaming has a similar structure but describes
a sliding window of a small range of from the live
program stream timeline (typically, 10 seconds of video). The sliding
window is updated for every new encoded (a range of chunks
defined by the attributes from="##" and to="##") of the program
stream. An example of a XML MPD for a Live scalable video content is
the following (Figure 5):
654321xyz
TRUE
06:56:18
1258
path/name
some description
Figure 5: XML MPD for a Live scalable video
The naming convention used to identify the media chunks
(segments/subsegments) considers a sequential numbering for
segments/subsegments, concatenated with the identifier of the
content, typically an alphanumeric string. For SVC and MDC contents,
a "leveltype" and a "level_id" are added. For MVC in 3D, a "view"
number is also added, immediately after the content identifier. The
resulting media chunks become named as follows:
Gu, et al. Expires May 2, 2012 [Page 16]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
SVC/MDC: <-><->.
MVC/3D:
<->-<->.
AVC: <->.
Where is the character V followed by the number of views,
is a character with values L for SVC Layers and D for MDC
descriptions, is a numeric value identifying the layer
(SVC) or description (MDC) and follows the common media content
extension naming.
Examples of the naming convention for a content_id="A123456789" are
as following:
SVC: A123456789-L0-00000.264 - chunk 0, layer 0 (subsegment BL)
SVC: A123456789-L1-00000.264 - chunk 0, layer 1 (subsegment EL)
MVC: A123456789-V2-L0-00000.264 - chunk 0, layer 0, view 2
MDC: A123456789-D0-0000.h264 - chunk 0, description 0
AAC: A123456789-00000.m4a - chunk 0
AVC: A123456789-00000.mp4 - chunk 0 (segment)
4 Messages syntax and processing
The PPSP Tracker Protocol messages follow the request and response
standard formats for HTTP Request and Response messages [RFC2616].
4.1 HTTP/XML Encoding
A Request message is a standard HTTP Request generated by the HTTP
Client Peer with the following syntax:
/ HTTP/1.1
Host:
Content-Lenght:
Content-Type:
The HTTP Method and URI path (the Resource) indicates the operation
requested. The current proposal uses only HTTP POST as a mechanism
for the request messages.
Gu, et al. Expires May 2, 2012 [Page 17]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
The Response message is also a standard HTTP Response generated by
the Tracker with the following syntax:
HTTP/1.1
Content-Lenght:
Content-Type:
Content-Encoding:
The Host header field in the Request message follows the standard
rules for the HTTP 1.1 Host Header. Other Header fields MAY be
included in the Request and Response messages if necessary.
The body for both Request and Response messages are encoded in XML
for all the PPSP Tracker Protocols messages, with the following
structure (the XML information being method specific):
***
***
***
***
###
...XML information specific of the Method...
In the XML body, the *** represents alphanumeric data and ###
represents numeric data to be inserted. The corresponds to
the method type for the message, the corresponds to the
response method type of the message and the element
uniquely identifies the transaction. Only one of Method or Response
will be present in any given method -- the presence of both
constitutes an error. The version of the PPSP Tracker Protocol being
used is in the form of a fixed point integer. The TransactionID is a
unique identifier for the transaction allowing receivers to
disambiguate transactions which would be otherwise identical.
Responses use the same TransactionID as the request they correspond
to.
All Request messages except CONNECT MUST include authentication
identity (PeerID) and authentication token [RFC4422]. The security
mechanism considers using re-keying service (key renegotiation
process) for the AuthToken [RFC4422].
The Response message MAY use Content-Encoding entity-header with
"gzip" compression scheme [RFC2616] for faster transmission times and
less network bandwidth usage.
Gu, et al. Expires May 2, 2012 [Page 18]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
The XML-Schema of PPSP Tracker Protocol is provided in Appendix A.
4.2 Method Fields
Table 2 and Table 3 define the valid string representations for the
requests and responses, respectively. These values MUST be treated
as case-insensitive.
+--------------------------+
| XML Request Value String |
+--------------------------+
| CONNECT |
| DISCONNECT |
| JOIN |
| LEAVE |
| FIND |
| STAT_REPORT |
| KEEPALIVE |
+--------------------------+
Table 2: Valid Strings for Requests
+----------------------+---------------------+--------------------+
| Response Method Name | HTTP Response | XML Response Value |
| | Mechanism | String |
+----------------------+---------------------+--------------------+
| SUCCESSFUL (OK) | 200 OK | OK |
| INVALID SYNTAX | 400 Bad Request | INVALID SYNTAX |
| VERSION NOT | 400 Bad Request | VERSION NOT |
| SUPPORTED | | SUPPORTED |
| AUTHENTICATION | 401 Unauthorized | AUTHENTICATION |
| REQUIRED | | REQUIRED |
| MESSAGE FORBIDDEN | 403 Forbidden | MESSAGE FORBIDDEN |
| OBJECT NOT FOUND | 404 Not Found | OBJECT NOT FOUND |
| INTERNAL ERROR | 500 Internal Server | INTERNAL ERROR |
| | Error | |
| TEMPORARILY | 503 Service | TEMPORARILY |
| OVERLOADED | Unavailable | OVERLOADED |
+----------------------+---------------------+--------------------+
Table 3: Valid Strings for Responses
4.3 Message Processing
When a PPSP Tracker Protocol message is received, some basic
processing is performed, regardless of the message type.
Gu, et al. Expires May 2, 2012 [Page 19]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
Upon reception, a message is examined to ensure that it is properly
formed. The receiver MUST check that the HTTP message itself is
properly formed, and if not, appropriate standard HTTP errors MUST be
generated. The receiver must also verify that the XML body is
properly formed.
If the message is found to be incorrectly formed or the length does
not match the length encoded in the header, the receiver MUST reply
with an HTTP 400 response with a PPSP XML body with the Response
method set to INVALID SYNTAX.
If the version number of the protocol is for a version the receiver
does not supports, the receiver MUST reply with an HTTP 400 response
with a PPSP XML body with the Response method set to VERSION NOT
SUPPORTED.
If the receiver is unable to process the message for being in an
overloaded state, the receiver SHOULD reply with an HTTP 503 response
with a PPSP XML body with the Response method set to TEMPORARILY
OVERLOADED.
If the receiver encounters an internal error while attempting to
process the message, the receiver MUST generate an HTTP 500 response
with a PPSP XML body with the Response method set to INTERNAL ERROR.
4.4 CONNECT Message
This method is used when a Peer connects to the system. The Tracker
records the PeerID, connect-time, IP address and link status.
The peer MUST properly form the XML body, set the Request Method to
CONNECT, randomly generate and set the TransactionID, set the PeerID
with the identifier of the peer and include the authentication
initial response [RFC4422]. The peer SHOULD also include the IP
addresses of its network interfaces in the CONNECT message.
Gu, et al. Expires May 2, 2012 [Page 20]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
The CONNECT Request message uses a HTTP POST method with the
following body:
CONNECT
***
AG1hZ251cwAxMjM0NT=
###
When receiving a well-formed CONNECT Request message, the Tracker
processes the peer authentication information to check whether it is
valid and that it can connect to the service. A Response message
with a corresponding response value and method will be generated.
The element MAY contain multiple child
elements with attributes "ip", "port", "priority" and "type"
corresponding to each of the network interfaces of the peer. The "ip"
attribute can be expressed in dotted decimal format for IPv4 or 16-
bit hexadecimal values (hh) separated by colons (:) for IPv6. The
attributes "priority" and "type" are related with NAT Traversal
service [I-D.li-ppsp-nat-traversal-02].
The Response message is a HTTP 200 OK with a SUCCESSFUL response in
case of success. In case of error one of the response methods of
Table 3 is returned. If STUN-like function is enabled in the Tracker,
the response MAY include the Peer reflexive address
[I-D.li-ppsp-nat-traversal-02]. The response MUST have the same
TransactionID value as the request and contain the Authentication
Token to be used by the Peer in subsequent messages until
disconnecting.
Gu, et al. Expires May 2, 2012 [Page 21]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
An example of the SUCCESSFUL Response message structure for the
CONNECT Request is the following:
OK
***
###
4.5 DISCONNECT message
This method is used when the Peer intends to leave the system and no
longer participate in any swarm. The Tracker deletes the
corresponding activity records related to the peer (including its
status and all content status for all swarms) updating the
information on the historical profile record of that peer.
The peer MUST properly form the XML body, set the Request Method to
DISCONNECT, set the PeerID with the identifier of the peer, randomly
generate and set the TransactionID and include the re-keyed
authentication token (AuthToken).
The DISCONNECT Request message uses a HTTP POST method with the
following body:
DISCONNECT
***
***
###
The Response message is an HTTP 200 OK with a SUCCESSFUL response in
case of success. In case of error one of the response methods of
Table 3 is returned. The response MUST have the same TransactionID
value as the request.
Upon receiving a DISCONNECT message, the Tracker MUST remove the peer
from the peer list and from all swarms the peer joined, as if a LEAVE
message was received for each swarm.
Gu, et al. Expires May 2, 2012 [Page 22]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
An example of the SUCCESSFUL Response message structure for the
DISCONNECT Request is the following:
OK
###
4.6 JOIN Message
This method is used for peers to notify the Tracker that they wish to
participate in a particular swarm.
The JOIN message is used when the peer has none or just some chunks
(LEECH), or has all the chunks (SEED) of a content. The JOIN is used
for both VoD or Live streaming modes.
The peer MUST properly form the XML body, set the Request Method to
JOIN, set the PeerID with the identifier of the peer, set the SwarmID
with the identifier of the swarm it is interested in, randomly
generate and set the TransactionID and include the re-keyed
authentication token (AuthToken). The peer MAY include an ExpireTime
set to a non-zero value expressed in seconds, indicating that the
peer expects to no longer be participating at the end of that time.
The ExpireTime MUST be set to zero if the peer does not wish to set
an expiration time.
The message also includes property information to indicate the
capabilities of the peer, such as NAT traversal information, PeerMode
set to the type of participation in the swarm (can be SEED, LIVESEED
or LEECH, but other qualifiers may additionally be defined) and also
the maximum number of candidates to be received in the Peer List,
when applicable.
Gu, et al. Expires May 2, 2012 [Page 23]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
The JOIN Request message uses a HTTP POST method with the following
body:
JOIN
***
***
***
***
true
###
***
###
###
OK
***
***
***
... more addresses ...
***
***
###
... Other peer info ...
###
Gu, et al. Expires May 2, 2012 [Page 25]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
4.7 LEAVE Message
This method is used when peers want to indicate to the Tracker that
they no longer wish to participate in a particular swarm. The Tracker
deletes the corresponding activity records related to the peer,
including its status and all content status for all swarms, updating
the information on the historical profile record of that peer.
The peer MUST properly form the XML body, set the Request Method to
LEAVE, set the PeerID with the identifier of the peer, set the
SwarmID with the identifier of the swarm the peer is not anymore
interested, randomly generate and set the TransactionID and include
the re-keyed authentication token (AuthToken).
The LEAVE Request message uses a HTTP POST method with the following
body:
LEAVE
***
***
***
###
OK
###
Gu, et al. Expires May 2, 2012 [Page 26]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
4.8 FIND Message
This method allows peers to request to the Tracker, whenever needed
and after being joined to a swarm, the peer list for the swarm or for
specific chunks of a media content representation of that swarm.
The peer MUST properly form the XML body, set the Request Method to
FIND, set the PeerID with the identifier of the peer, set the SwarmID
with the identifier of the swarm the peer is interested, optionally,
in order to find specific chunks, include information about the
content, like Clip Name, type and the segment IDs, randomly generate
and set the TransactionID and include authentication token
(AuthToken). The message also includes property information to
indicate the capabilities of the peer, such as NAT traversal
information.
The Request message uses a HTTP POST method with the following body:
FIND
***
***
***
###
true
***
###
When receiving a well-formed FIND Request message, the Tracker
processes the peer authentication information to check whether it is
valid and can be authorized.
If the request is valid, a Response message with a corresponding
response value and method will be generated and the Tracker will
search the internal data store to select and return an appropriate
list of peers, with their identifiers and IP Addresses, that will be
able to provide the desired content.
The Tracker may take peer status and priority information into
Gu, et al. Expires May 2, 2012 [Page 27]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
consideration when selecting the peer list candidates and the
selection may change in subsequent requests to express network
topology preferences or Operators' policy preferences, with regard to
the possibility of connecting with other IETF efforts such as ALTO
[I.D.ietf-alto-protocol].
The Response message is an HTTP 200 OK SUCCESSFUL message in case of
success. The Tracker MUST reject the FIND message with an HTTP 400
Bad Request Response with a PPSP XML body of INVALID SYNTAX if this
condition has occurred, or for other conditions, with one of the
response methods of Table 3. If the data is not found (find chunk
option) an HTTP 404 Not Found with a PPSP XML Response method set to
OBJECT NOT FOUND.The response MUST have the same TransactionID value
as the request.
An example of the SUCCESSFUL Response message structure for the FIND
request is the following:
OK
***
###
***
***
... more addresses ...
***
***
###
... Other peer info ...
The field record in the XML body can be instantiated
multiple times in the element, one instance per peer.
The PeerLocation, ConnectionType and EndPointRankCost express network
topology preferences or Operators' policy preferences, related with
Gu, et al. Expires May 2, 2012 [Page 28]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
the possibility of connecting with other IETF efforts such as ALTO
[I.D.ietf-alto-protocol]
The response message also carries information associated with network
topology information for each peer listed.
4.9 STAT_REPORT Message
This method allows the exchange of statistic and status data between
peers and Trackers to improve system performance. The method is
initiated by the peer, periodically while active.
The peer MUST properly form the XML body, set the Request Method to
STAT_REPORT, set the PeerID with the identifier of the peer, randomly
generate and set the TransactionID, include authentication token
(AuthToken). The report consists of a element in the XML body
containing multiple fields.
The field record in the XML body can be instantiated multiple
times in the element, one instance per "property" to report.
If the property being reported is associated with a swarm then the
peer MUST set the SwarmID element with the identifier of the swarm
and include other relevant information like Clip Name, Type and
information of the content.
The properties listed in Table 4 correspond to the REQUIRED minimum
set of information for the STAT_REPORT, but additional properties are
deemed to be defined in the future.
+-------------------+----------------------------------------------+
| Property Value | Definitions/Description |
+-------------------+----------------------------------------------+
| ChunkMap | a base64 encoded bitmap of chunks available |
| StreamStats | information on network streaming: |
| :UploadedBytes | total bytes sent to other peers in the swarm |
| :DownloadedBytes | total bytes received from peers in the swarm |
| :AvailBandwidth | total bytes received from peers in the swarm |
| NAT Traversal | The type of NAT Traversal capabilities |
| :NAT | Peer believes it is behind NAT (boolean) |
| :STUN | Peer supports STUN service (boolean) |
+------------------+-----------------------------------------------+
Table 4: Minimum set of Property Types for STAT_REPORT messages
Gu, et al. Expires May 2, 2012 [Page 29]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
The STAT_REPORT Request message uses a HTTP POST method with the
following body:
STAT_REPORT
***
***
###
***
***
... encoded string ...
***
###
###
###
When receiving a well-formed STAT_REPORT message, the Tracker
processes the peer authentication information to check whether it is
valid.
If the request is valid, a Response message with a corresponding
response value and method will be generated and the tracker MAY
process the received information for future use.
The Response message is an HTTP 200 OK SUCCESSFUL message in case of
success. The Tracker MUST reject the STAT_REPORT message with an HTTP
400 Bad Request Response with a PPSP XML body of INVALID SYNTAX if
this condition has occurred, or for other conditions, with one of the
response methods of Table 3. The response MUST have the same
Gu, et al. Expires May 2, 2012 [Page 30]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
TransactionID value as the request.
An example of the SUCCESSFUL Response message structure for the
STAT_REPORT is the following:
OK
###
4.10 KEEPALIVE Message
These messages are periodically sent from peers to the Tracker to
notify it that the peer is still alive (although not actively
exchanging data with other peers), to prevent the Tracker from
disconnecting the Peer (after some pre-configured time) by assuming
that the peer was no longer available.
The peer MUST properly form the XML body, set the Request Method to
KEEPALIVE, set the PeerID with the identifier of the peer, randomly
generate and set the TransactionID and include authentication token
(AuthToken).
The KEEPALIVE Request message uses a HTTP POST method with the
following body:
KEEPALIVE
***
***
###
When receiving a well-formed KEEPALIVE message, the Tracker processes
the peer and user authentication information to check whether they
are valid.
If the request is valid, a Response message with a corresponding
response value and method will be generated and the tracker SHOULD
update an internal timer to indicate that the tracker has heard from
the peer.
The Response message is an HTTP 200 OK SUCCESSFUL message in case of
success. The Tracker MUST reject the KEEPALIVE message with an HTTP
400 Bad Request Response with a PPSP XML body of INVALID SYNTAX if
this condition has occurred, or for other conditions, with one of the
Gu, et al. Expires May 2, 2012 [Page 31]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
response methods of Table 2. The response MUST have the same
TransactionID value as the request.
An example of the SUCCESSFUL Response message structure for the
KEEPALIVE is the following:
OK
###
5 Security Considerations
P2P streaming systems are subject to attacks by malicious/unfriendly
peers/trackers that may eavesdrop on signaling, forge/deny
information/knowledge about streaming content and/or its
availability, impersonating to be another valid participant, or
launch DoS attacks to a chosen victim.
No security system can guarantees complete security in an open P2P
streaming system where participants may be malicious or
uncooperative. The goal of security considerations described here is
to provide sufficient protection for maintaining some security
properties during the tracker-peer communication even in the face of
a large number of malicious peers and/or eventual distrustful
trackers (under the distributed tracker deployment scenario).
Since the protocol uses HTTP to transfer signaling most of the same
security considerations described in RFC 2616 also apply [RFC2616].
5.1 Authentication between Tracker and Peers
To protect the PPSP signaling from attackers pretending to be valid
peers (or peers other than themselves) all messages received in the
Tracker are required to be received from authorized peers.
For that purpose a peer must enroll in the system via a centralized
enrollment server. The enrollment server is expected to provide a
proper PeerID for the peer and information about the authentication
mechanisms. The specification of the enrollment method and the
provision of identifiers and authentication tokens is out of scope of
this draft.
The method for adding authentication and data security services via
replaceable mechanisms to the PPSP Tracker Protocol (connection-
oriented) is the Simple Authentication and Security Layer (SASL)
framework [RFC4422].
Gu, et al. Expires May 2, 2012 [Page 32]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
The SASL method also provides the means for negotiating data security
layer mechanisms to provide data integrity, data confidentiality, and
other services, subject to local policies and security requirements.
The authentication exchange between Peer and Tracker consists of a
CONNECT message from the Peer to the Tracker requesting
authentication via a particular mechanism, followed by a message from
the Tracker indicating the outcome of the authentication exchange
(the AuthToken).
C: Request authentication exchange + Initial response
S: Outcome of authentication exchange
All subsequent messages, while the Peer is active will use the
AuthToken, and the security mechanism considers using re-keying
service (key renegotiation process) for the AuthToken [RFC4422].
5.2 Content Integrity protection against polluting peers/trackers
Malicious peers may declaim ownership of popular content to the
Tracker but serve polluted (i.e., decoy content or even virus/trojan
infected contents) to other peers. This kind of pollution can be
detected by incorporating a checksum distribution scheme for
published sharing content. As content chunks of the same content are
transferred independently and concurrently, correspondent chunk-level
checksums MUST be distributed from an authentic origin.
5.3 Residual attacks and mitigation
To mitigate the impact of sybil attackers, impersonating a large
number of valid participants by repeatedly acquiring different peer
identities, the enrollment server SHOULD carefully regulate the rate
of peer/tracker admission.
There is no guarantee that a peer honestly report its status to the
Tracker, or server authentic content to other peers as it claims to
the Tracker. It is expected that a global trust mechanism, where the
credit of each peer is accumulated from evaluations for previous
transactions, may be taken into account by other peers when selecting
partner for future transactions, helping to mitigate the impact of
such malicious behaviors. A globally trusted Tracker MAY also take
part of the trust mechanism by collecting evaluations, computing
credit values and providing them to joining peers.
5.4 Pro-incentive parameter trustfulness
Property Types for STAT_REPORT messages will consider pro-incentive
Gu, et al. Expires May 2, 2012 [Page 33]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
parameters, which can enable the Tracker to improve the performance
of the whole P2P streaming system. Trustworthiness of these pro-
incentive parameters is critical to the effectiveness of the
incentive mechanisms. For example, ChunkMap is essential, and needs
to be accurate. The P2P system should be designed in a way such that
a peer will have the incentive to report truthfully its ChunkMap
(otherwise it may penalize itself, as in the case of under-reporting
addressed in [prTorrent]).
Furthermore, both the amount of upload and download should be
reported to the Tracker to allow checking if there is any
inconsistency between the upload and download report, and establish
an appropriate credit/trust system. Alternatively, exchange of
cryptographic receipts signed by receiving peers can be used to
attest to the upload contribution of a peer to the swarm, as
suggested in [Contracts].
6 PPSP Requirements Compliance
6.1 PPSP Basic Requirements
PPSP.REQ-1: The design of the Tracker protocol in this draft allows
the Peer Protocol to be similar in terms of design, message formats
and flows.
PPSP.REQ-2: The design of the Tracker protocol in this draft enables
peers to receive streaming content within required time constraints.
PPSP.REQ-3: Each Peer has a unique ID (i.e., PeerID) that identifies
the Peer in all swarms joined.
PPSP.REQ-4: Each streaming content is uniquely identified by a
SwarmID.
PPSP.REQ-5: The streaming content is partitioned into chunks
individually addressable.
PPSP.REQ-6: Each chunk has an unique ID in the swarm and is
individually addressable.
PPSP.REQ-7: The Tracker Protocol is carried over TCP.
PPSP.REQ-8: The Tracker Protocol is designed to facilitate acceptable
QoS, supporting, without special algorithms, adaptive and scalable
video and 3D video, for both Video On Demand (VoD) and Live video
services, allowing additionally complementary mechanisms like super
peers, in-network storage, alternative peer addresses and usage of
QoS information for advanced peer selection.
Gu, et al. Expires May 2, 2012 [Page 34]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
6.2 PPSP Tracker Protocol Requirements
PPSP.TP.REQ-1: The Tracker Protocol implements the reception of
queries from peers, such as those in JOIN and FIND messages and
periodical peer status reports (STAT_REPORT), as well as the
corresponding replies.
PPSP.TP.REQ-2: The peer MUST implement the Tracker Protocol designed
in this draft.
PPSP.TP.REQ-3: The tracker request messages JOIN and FIND allow the
requesting of peer list from the Tracker with respect to a specific
SwarmID and include preferred number of peers in the peer list as
well as peer properties which enable appropriate candidate peer
selections by the Tracker.
PPSP.TP.REQ-4: The tracker replies to JOIN and FIND messages allow
the Tracker to offer the peer list to the requesting peer with
respect of a specific SwarmID.
PPSP.TP.REQ-5: The Tracker supports generating the peer lists with
the help of traffic optimization services like ALTO.
PPSP.TP.REQ-6: The STATUS_REPORT message informs the Tracker about
the peer's activity in the swarm.
PPSP.TP.REQ-7: The chunk availability information (ChunkMaps) of the
Peer (for all joined swarms) is reported to the Tracker in
STATUS_REPORT messages.
PPSP.TP.REQ-8: The ChunkMaps exchanged between Peer and Tracker are
expressed as compact encoded strings.
PPSP.TP.REQ-9: The STATUS_REPORT message informs the Tracker about
the Peer status and capabilities.
6.3 PPSP Security Considerations
PPSP.SEC.REQ-1: The Tracker Protocol supports closed swarms, where
the peers are required to be authenticated.
PPSP.SEC.REQ-2: Confidentiality of the streaming content can be
supported, and the corresponding key management mechanisms can be
negotiated in the authentication and authorization phase (via CONNECT
message) before the peer JOINing the swarm.
PPSP.SEC.REQ-3: The Tracker Protocol uses SASL mechanisms with option
to negotiate additional security layers to encrypt the data exchanged
Gu, et al. Expires May 2, 2012 [Page 35]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
among the PPSP entities.
PPSP.SEC.REQ-4: The Tracker Protocol SASL mechanisms help to limit
potential damages caused by malfunctioning and badly behaving peers
in the P2P streaming system. The streaming mechanism, being pull-
based, even in Live Streaming, prevents pollution of contents.
PPSP.SEC.REQ-6: The use of trusted Trackers and Peer authentication
and authorization mechanisms capable to provide additional security
and confidentiality, allow to mitigate and prevent peers from DoS
attacks.
PPSP.SEC.REQ-7: The Tracker Protocol design supports distributed
tracker architectures, providing robustness to the streaming service
in case of centralized Tracker failure.
PPSP.SEC.REQ-8: The Tracker Protocol use of SASL mechanisms avoid the
need for developing new security mechanisms.
PPSP.SEC.REQ-9: The Tracker Protocol together with the Media
Presentation Description (MPD) allow the use of streaming content
integrity mechanisms.
7 IANA Considerations
There are presently no IANA considerations with this document.
8 Acknowledgments
The authors would like to thank many people for for their help and
comments, particularly: Zhang Yunfei, Liao Hongluan, Roni Even,
Bhumip Khasnabish, Wu Yichuan, Peng Jin, Chi Jing, Zong Ning, Song
Haibin, Chen wei, Zhijia Chen, Christian Schmidt, Lars Eggert, David
Harrington, Henning Schulzrinne, Kangheng Wu., Martin Stiemerling
from NEC Labs, Johan Pouwelse and Arno Bakker form TU Delft.
The authors would also like to thank the people participating in the
EU FP7 project SARACEN (contract no. ICT-248474)
[refs.saracenwebpage] for contributions and feedback to this
document.
The views and conclusions contained herein are those of the authors
and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the SARACEN project or the European Commission.
Gu, et al. Expires May 2, 2012 [Page 36]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
9 References
9.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, May 1996.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422, June
2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[ISO.8601.2004] International Organization for Standardization, "Data
elements and interchange formats - Information interchange
- Representation of dates and times", ISO Standard 8601,
December 2004.
9.2 Informative References
[I-D.ietf-ppsp-reqs] Zong, N., Zhang, Y., Avila, V., Williams, C.,
and L. Xiao, "P2P Streaming Protocol (PPSP)
Requirements", draft-ietf-ppsp-reqs-02 (work in progress),
February 2011.
[I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G.,
Seng, J., and Y. Yang, "Problem Statement of P2P Streaming
Protocol (PPSP)", draft-ietf-ppsp-problem-statement-01
(work in progress), January 2011.
[I-D.ietf-ppsp-survey] Yingjie, G., Zong, N., Zhang, H., Zhang, Y.,
Lei, J., Camarillo, G., and L. Yong, "Survey of P2P
Streaming Applications", draft-gu-ppsp-survey-02 (work in
progress), March 2011.
[I-D.cruz-ppsp-http-peer-protocol] Cruz, R., Nunes, M. and Taveira,
J., "HTTP-based PPSP Peer Protocol", draft-cruz-ppsp-http-
peer-protocol-00 (work in progress), May 2011.
Gu, et al. Expires May 2, 2012 [Page 37]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
[I-D.gu-ppsp-tracker-protocol] Yingjie, G., Bryan, D., Zhang, Y., and
H. liao, "PPSP Tracker Protocol", draft-gu-ppsp-tracker-
protocol-04 (work in progress), May 2011.
[I-D.li-ppsp-nat-traversal-02] Li, L., Wang, J., Chen, W., "PPSP NAT
Traversal", draft-li-ppsp-nat-traversal-02 (work in
progress), July 2011.
[I-D.xiao-ppsp-reload-distributed-tracker] Xiao, L., Bryan, D., Gu,
Y., Tai, X., "A PPSP Tracker Usage for Reload", draft-
xiao-ppsp-reload-distributed-tracker-03 (work in
progress), October 2011.
[I.D.ietf-alto-protocol] Alimi, R., Penno, R., Yang, Y., "ALTO
Protocol", draft-ietf-alto-protocol-09, (work in
progress), June 2011.
[MP4-Reg] MP4REG, The MPEG-4 Registration Authority, URL:
.
[ISO.IEC.23001-6] International Organization for
Standardization/International Electrotechnical Commission,
"Information technology - MPEG systems technologies - Part
6: Dynamic adaptive streaming over HTTP (DASH)", ISO/IEC
DIS 23001-6, Jan 2011.
[refs.saracenwebpage] "SARACEN Project Website",
http://www.saracen-p2p.eu/.
[prTorrent] Roy, S., Zeng, W., "prTorrent: On Establishment of Piece
Rarity in the BitTorrent Unchoking Algorithm", in IEEE
Ninth International Conference on Peer-to-Peer Computing,
September 2009.
[Contracts] Piatek, M., Venkataramani, A., Yang, R., Zhang, D.,
Jaffe, A., "Contracts: Practical Contribution Incentives
for P2P Live Streaming", in NSDI '10: USENIX Symposium on
Networked Systems Design and Implementation, April 2010.
Appendix A. PPSP Tracker Protocol XML-Schema
Gu, et al. Expires May 2, 2012 [Page 38]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
Gu, et al. Expires May 2, 2012 [Page 39]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
Gu, et al. Expires May 2, 2012 [Page 40]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
Gu, et al. Expires May 2, 2012 [Page 41]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
Gu, et al. Expires May 2, 2012 [Page 42]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
Authors' Addresses
Rui Santos Cruz
IST/INESC-ID/INOV
Phone: +351.939060939
Email: rui.cruz@ieee.org
Gu Yingjie
Huawei
Phone: +86-25-56624760
Fax: +86-25-56624702
Email: guyingjie@huawei.com
Mario Serafim Nunes
IST/INESC-ID/INOV
Rua Alves Redol, n.9
1000-029 LISBOA, Portugal
Phone: +351.213100256
Email: mario.nunes@inov.pt
David A. Bryan
Polycom
P.O. Box 6741
Gu, et al. Expires May 2, 2012 [Page 43]
INTERNET DRAFT PPSP Tracker Protocol October 30, 2011
Williamsburg, Virginia 23188
United States of America
Phone: +1.571.314.0256
Email: dbryan@ethernot.org
Jinwei Xia
Huawei
Nanjing, Baixia District 210001
China
Phone: +86-025-86622310
Email: xiajinwei@huawei.com
Joao P. Taveira
IST/INOV
Email: joao.silva@inov.pt
Deng Lingli
China Mobile
Gu, et al. Expires May 2, 2012 [Page 44]