5. Operations and Manageability
This section provides the operational and management aspects that are
required to be considered in implementations of PPSTP. These aspects
follow the recommendations expressed in [RFC5706].
5.1. Operational Considerations
PPSTP provides communication between trackers and peers and is
conceived as a "client-server" mechanism, allowing the exchange of
information about the participant peers sharing multimedia streaming
The "server" component, i.e., the tracker, is a logical entity that
can be envisioned as a centralized service (implemented in one or
more physical nodes) or a fully distributed service.
The "client" component can be implemented at each peer participating
in the streaming of content.
5.1.1. Installation and Initial Setup
Content providers wishing to use PPSP for content distribution should
set up at least a PPSP tracker and a service portal (public web
server) to publish links of the content descriptions, for access to
their on-demand or live original content sources. Content and
service providers should also create conditions to generate peer IDs
and any required security certificates, as well as chunk IDs and
swarm IDs for each streaming content. The configuration processes
for the PPSP tracking facility, the service portal, and content
sources are not standardized, enabling flexibility for implementers.
The swarm IDs of available content, as well as the addresses of the
PPSP tracking facility, can be distributed to end users in various
ways, but it is common practice to include both the swarm ID and the
corresponding PPSP tracker addresses (as URLs) in the MPD of the
content, which is obtainable (a link) from the service portal.
The available content could have different importance attribute
values to indicate whether the content is popular or not. However,
it is a totally implementation design and outside the scope of this
specification. For example, the importance attribute values of the
content could be set by content providers when distributing them or
could be determined by the tracker based on the statistics of the
requests from the peers that request the content. The tracker could
set an upper threshold to decide that the content is popular enough
when the importance attribute value is higher than the upper
threshold. The tracker could also set a lower threshold to decide
that the content is uncommon enough when the importance attribute
value is lower than the lower threshold.
End users browse and search for desired content in the service portal
and select by clicking the links of the corresponding MPDs. This
action typically requires security certificates or authorization
tokens from an enrollment service (end-user registration) and then
launches the Client Media Player (with PPSP awareness), which will
then, using PPSTP, contact the PPSP tracker to join the corresponding
swarm and obtain the transport addresses of other PPSP peers in order
to start streaming the content.
5.1.2. Migration Path
There is no previous standard protocol providing functionality
similar to PPSTP. However, some popular proprietary protocols, e.g.,
BitTorrent, are used in existing systems. There is no way for PPSTP
to migrate to proprietary protocols like the BitTorrent tracker
protocol. Because PPSTP is an application-level protocol, there is
no harm in PPSTP having no migration path. However, proprietary
protocols migrating to standard protocols like PPSTP can solve the
problems raised in [RFC6972]. It is also possible for systems to use
PPSTP as the management protocol to work with exiting propriety peer
protocols like the BitTorrent peer protocol.
5.1.3. Requirements on Other Protocols and Functional Components
For security reasons, when using the Peer-to-Peer Streaming Peer
Protocol (PPSPP) with PPSTP, the mechanisms described in Section 6.1
should be observed.
5.1.4. Impact on Network Operation
As the messaging model of PPSTP aligns with HTTP and the semantics of
its messages, the impact on network operation is similar to using
5.1.5. Verifying Correct Operation
The correct operation of PPSTP can be verified both at the tracker
and at the peer by logging the behavior of PPSTP. Additionally, the
PPSP tracker collects the status of the peers, including the peers'
activity; such information can be used to monitor and obtain the
global view of the operation.
5.2. Management Considerations
The management considerations for PPSTP are similar to other
solutions using HTTP for large-scale content distribution. The PPSP
tracker can be realized by geographically distributed tracker nodes
or multiple server nodes in a data center. As these nodes are akin
to WWW nodes, their configuration procedures, detection of faults,
measurement of performance, usage accounting, and security measures
can be achieved by standard solutions and facilities.
Interoperability refers to allowing information sharing and
operations between multiple devices and multiple management
applications. For PPSTP, distinct types of devices host PPSTP
trackers and peers. Therefore, support for multiple standard schema
languages, management protocols, and information models, suited to
different purposes, was considered in the PPSTP design.
Specifically, management functionality for PPSTP devices can be
achieved with the Simple Network Management Protocol (SNMP)
[RFC3410], syslog [RFC5424], and the Network Configuration Protocol
5.2.2. Management Information
PPSP trackers may implement SNMP management interfaces, namely, the
Application Management MIB [RFC2564], without the need to instrument
the tracker application itself. The channel, connections, and
transaction objects of the Application Management MIB can be used to
report the basic behavior of the PPSP tracker service.
The Application Performance Measurement MIB (APM-MIB) [RFC3729] and
the Transport Performance Metrics MIB (TPM-MIB) [RFC4150] can be used
with PPSTP to provide adequate metrics for the analysis of
performance for transaction flows in the network, in direct
relationship to the transport of PPSTP.
The Host Resources MIB [RFC2790] can be used to supply information on
the hardware, the operating system, and the installed and running
software on a PPSP tracker host.
The TCP-MIB [RFC4022] can additionally be considered for network
Logging is an important functionality for PPSTP trackers and peers;
it is done via syslog [RFC5424].
5.2.3. Fault Management
As PPSP tracker failures can be mainly attributed to host or network
conditions, the facilities previously described for verifying the
correct operation of PPSTP and the management of PPSP tracker servers
appear sufficient for PPSTP fault monitoring.
5.2.4. Configuration Management
PPSP tracker deployments, when realized by geographically distributed
tracker nodes or multiple server nodes in a data center, may benefit
from a standard way of replicating atomic configuration updates over
a set of server nodes. This functionality can be provided via
5.2.5. Accounting Management
PPSTP implementations, primarily in content provider environments,
can benefit from accounting standardization efforts as described in
[RFC2975], which indicates that accounting management is "concerned
with the collection of resource consumption data for the purposes of
capacity and trend analysis, cost allocation, auditing, and billing".
5.2.6. Performance Management
Because PPSTP is transaction oriented, its performance in terms of
availability and responsiveness can be measured with the facilities
of the APM-MIB [RFC3729] and the TPM-MIB [RFC4150].
5.2.7. Security Management
Standard SNMP notifications for PPSP tracker management [RFC5590] and
syslog messages [RFC5424] can be used to alert operators to the
conditions identified in the security considerations (Section 6).
The statistics collected about the operation of PPSTP can be used for
detecting attacks (e.g., the receipt of malformed messages, messages
out of order, or messages with invalid timestamps). However,
collecting such endpoint properties may also raise some security
issues. For example, the statistics collected by the tracker may be
disclosed to an unauthorized third party that has malicious
intentions. To address such risk, the provider of the tracker should
evaluate how much information is revealed and the associated risks.
A confidentiality mechanism must be provided by HTTP over TLS to
guarantee the confidentiality of PPSTP.
6. Security Considerations
P2P streaming systems are subject to attacks by malicious or
unfriendly peers/trackers that may eavesdrop on signaling, forge/deny
information/knowledge about streaming content and/or its
availability, impersonate a valid participant, or launch DoS attacks
on a chosen victim.
No security system can guarantee complete security in an open P2P
streaming system where participants may be malicious or
uncooperative. The goal of the security considerations described
here is to provide sufficient protection for maintaining some
security properties during 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
security considerations described in [RFC7230] and [RFC7231] also
apply. Due to the transactional nature of the communication between
peers and tracker, the method for adding authentication and data
security services can be the OAuth 2.0 Authorization [RFC6749] with a
bearer token, which provides the peer with the information required
to successfully utilize an access token to make protected requests to
6.1. Authentication between Tracker and Peers
To protect PPSTP signaling from attackers pretending to be valid
peers (or peers other than themselves), all messages received in the
tracker SHOULD be received from authorized peers. For that purpose,
a peer SHOULD enroll in the system via a centralized enrollment
server. The enrollment server is expected to provide a proper peer
ID 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 the scope of this
Transport Layer Security (TLS) [RFC5246] MUST be used in the
communication between peers and tracker to provide privacy and data
integrity. Software engineers developing and service providers
deploying the tracker should make themselves familiar with the Best
Current Practices (BCP) on configuring HTTP over TLS [RFC7525].
OAuth 2.0 Authorization [RFC6749] SHOULD also be considered when
digest authentication [RFC7616] and HTTPS client certificates are
6.2. Content Integrity Protection against Polluting Peers/Trackers
Malicious peers may claim ownership of popular content to the tracker
and try to serve polluted (i.e., decoy content or even virus/trojan-
infected content) to other peers. Since trackers do not exchange
content information among peers, it is difficult to detect whether or
not a peer is polluting the content. Usually, this kind of pollution
can be detected by the Peer-to-Peer Streaming Peer Protocol (PPSPP)
[RFC7574] with requiring the use of Merkle Hash Tree scheme for
protecting the integrity of the content. More details can be seen in
Section 5 of [RFC7574].
Some attackers that disrupt P2P streaming on behalf of content
providers may provide false or modified content or peer list
information to achieve certain malicious goals. Peers connecting to
those portals or trackers provided by the attackers may be redirected
to some corrupted malicious content. However, there is no standard
way for peers to avoid this kind of situation completely. Peers can
have mechanisms to detect undesirable content or results themselves.
For example, if a peer finds that the portal returned some undesired
content information or the tracker returned some malicious peer
lists, the peer may choose to quit the swarm or switch to other P2P
streaming services provided by other content providers.
6.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 peers honestly report their status to the
tracker, or serve authentic content to other peers as they claim 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
partners for future transactions, helping to mitigate the impact of
such malicious behaviors. A globally trusted tracker may also take
part in the trust mechanism by collecting evaluations, computing
credit values, and providing them to joining peers.
6.4. Pro-incentive Parameter Trustfulness
Property types for STAT_REPORT messages may consider additional pro-
incentive parameters (see the guidelines for extension in Section 7),
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. Furthermore, the amount of both uploaded and downloaded
data should be reported to the tracker to allow checking for
inconsistencies between the upload and download report and to
establish an appropriate credit/trust system.
One such solution could be a reputation-incentive mechanism, based on
the notions of reputation, social awareness, and fairness. The
mechanism would promote cooperation among participants (via each
peer's reputation) based on the history of past transactions, such
as, count of chunk requests (sent and received) in a swarm,
contribution time of the peer, cumulative uploaded and downloaded
content, JOIN and LEAVE timestamps, attainable rate, etc.
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.5 Privacy for Peers
PPSTP provides mechanisms in which the peers can send messages
containing IP addresses, ports, and other information to the tracker.
A tracker or a third party who is able to intercept such messages can
store and process the obtained information in order to analyze peers'
behaviors and communication patterns. Such analysis can lead to
privacy risks. For example, an unauthorized party may snoop on the
data transmission from the peer to a tracker in order to introduce
some corrupted chunks.
The Peer-to-Peer Streaming Peer Protocol (PPSPP) [RFC7574] has
already introduced some mechanisms to protect streamed content; see
Sections 12.3 and 12.4 of [RFC7574]. For PPSTP, peer implementations
as well as tracker implementations MUST support the "https" URI
scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. In
addition, a peer should be cognizant about potential trackers
tracking through queries of peers, e.g., by using HTTP cookies.
PPSTP as specified in this document does not rely on HTTP cookies.
Thus, peers may decide not to return cookies received from the
tracker, in order to make additional tracking more difficult.
7. Guidelines for Extending PPSTP
Extension mechanisms allow designers to add new features or to
customize existing features of a protocol for different operating
Extending a protocol implies either the addition of features without
changing the protocol itself or the addition of new elements creating
new versions of an existing schema and therefore new versions of the
In PPSTP, this means that an extension MUST NOT alter an existing
protocol schema as the changes would result in a new version of an
existing schema, not an extension of an existing schema, typically
Additionally, a designer MUST remember that extensions themselves may
also be extensible.
Extensions MUST adhere to the principles described in this section in
order to be considered valid.
Extensions MUST be documented in Standards Track RFCs if there are
requirements for coordination, interoperability, and broad
7.1. Forms of PPSTP Extension
In PPSTP, two extension mechanisms can be used: a Request-Response
Extension or a Protocol-Level Extension.
o Request-Response Extension: Adding elements or attributes to an
existing element mapping in the schema is the simplest form of
extension. This form should be explored before any other. This
task can be accomplished by extending an existing element mapping.
For example, an element mapping for the Statistics Group can be
extended to include additional elements needed to express status
information about the activity of the peer, such as online time
for the stat element.
o Protocol-Level Extension: If there is no existing element mapping
that can be extended to meet the requirements and the existing
PPSTP request and response message structures are insufficient,
then extending the protocol should be considered in order to
define new operational requests and responses.
For example, to enhance the level of control and the granularity
of the operations, a new version of the protocol with new messages
(JOIN, DISCONNECT), a retro-compatible change in semantics of an
existing CONNECT request/response, and an extension in STAT_REPORT
could be considered.
As illustrated in Figure 6, the peer would use an enhanced CONNECT
request to perform the initial registration in the system. Then
it would join a first swarm as SEEDER, later join a second swarm
as LEECH, and then disconnect from the latter swarm but remain as
SEEDER for the first one. When deciding to leave the system, the
peer disconnects gracefully from it:
| Peer | | Tracker |
Figure 6: Example of a Session for a PPSTP Extended Version
7.2. Issues to Be Addressed in PPSTP Extensions
There are several issues that all extensions should take into
o Overview of the Extension: It is RECOMMENDED that extensions to
PPSTP have a protocol overview section that discusses the basic
operation of the extension. The most important processing rules
for the elements in the message flows SHOULD also be mentioned.
o Backward Compatibility: The new extension MUST be backward
compatible with the base PPSTP specified in this document.
o Syntactic Issues: Extensions that define new request/response
methods SHOULD use all capitals for the method name, keeping with
a long-standing convention in many protocols, such as HTTP.
Method names are case sensitive in PPSTP. Method names SHOULD be
shorter than 16 characters and SHOULD attempt to convey the
general meaning of the request or response.
o Semantic Issues: PPSTP extensions MUST clearly define the
semantics of the extensions. Specifically, the extension MUST
specify the behaviors expected from both the peer and the tracker
in processing the extension, with the processing rules in temporal
order of the common messaging scenario.
Processing rules generally specify actions to be taken on receipt
of messages and expiration of timers.
The extension SHOULD specify procedures to be taken in exceptional
conditions that are recoverable. Handling of unrecoverable errors
does not require specification.
o Security Issues: As security is an important component of any
protocol, designers of PPSTP extensions need to carefully consider
security requirements, e.g., authorization requirements and
requirements for end-to-end integrity.
o Examples of Usage: The specification of the extension SHOULD give
examples of message flows and message formatting and include
examples of messages containing new syntax. Examples of message
flows should be given to cover common cases and at least one
failure or unusual case.
8. IANA Considerations
8.1. MIME Type Registry
This document registers "application/ppsp-tracker+json" media types.
Type name: application
Subtype name: ppsp-tracker+json
Required parameters: n/a
Optional parameters: n/a
Encoding considerations: Encoding considerations are identical to
those specified for the "application/json" media type. See
Security considerations: See Section 6 of RFC 7846.
Interoperability considerations: This document specifies the format
of conforming messages and the interpretation thereof.
Published specification: RFC 7846.
Applications that use this media type: PPSP trackers and peers
either stand alone or are embedded within other applications.
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
Fragment identifier considerations: n/a
Person & email address to contact for further information: See
Authors' Addresses section.
Intended usage: COMMON
Restrictions on usage: none
Author: See Authors' Addresses section of RFC 7846.
Change controller: IESG (firstname.lastname@example.org)
8.2. PPSTP Version Number Registry
IANA has created the "PPSTP Version Number Registry". Values are
integers in the range 0-255, with initial assignments and
reservations given in Table 2. New PPSTP version types are assigned
after IETF Review [RFC5226] to ensure that proper documentation
regarding the new version types and their usage has been provided.
8.3. PPSTP Request Type Registry
IANA has created the "PPSTP Request Type Registry". Values are
strings listed in Table 8. New PPSTP request types are assigned
after IETF Review [RFC5226] to ensure that proper documentation
regarding the new request types and their usage has been provided.
| request_type | Description |
| "CONNECT" | Returns information about the successful |
| | registration of the peer and/or of each |
| | swarm action requested. May additionally |
| | return the list of peers corresponding to |
| | the action attribute |
| | requested. |
| | |
| "FIND" | Returns the list of peers corresponding |
| | to the requested scope. |
| | |
| "STAT_REPORT" | Confirms the success of the requested |
| | operation. |
Table 8: The PPSTP Request Type Registry
8.4. PPSTP Error Code Registry
IANA has created the "PPSTP Error Code Registry". Values are the
strings listed in Table 9. New PPSTP error codes are assigned after
IETF Review [RFC5226] to ensure that proper documentation regarding
the new error codes and their usage has been provided.
| error_code | Description |
| 00 | No Error |
| 01 | Bad Request |
| 02 | Unsupported Version Number |
| 03 | Forbidden Action |
| 04 | Internal Server Error |
| 05 | Service Unavailable |
| 06 | Authentication Required |
Table 9: The PPSTP Error Code Registry
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI
10.17487/RFC5424, March 2009,
[RFC5706] Harrington, D., "Guidelines for Considering Operations
and Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009,
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012,
[RFC6972] Zhang, Y. and N. Zong, "Problem Statement and
Requirements of the Peer-to-Peer Streaming Protocol
(PPSP)", RFC 6972, DOI 10.17487/RFC6972, July 2013,
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
[SARACEN] Sarecen P2P, <http://www.saracen-p2p.eu/>.
The authors appreciate the contributions made by Yingjie Gu in the
early stages of the specification. Also, they thank the following
people for their help and comments: Zhang Yunfei, Liao Hongluan, Roni
Even, Dave Cottlehuber, 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, Jianyin Zhang, Johan Pouwelse, Riccardo
Petrocco, and Arno Bakker.
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 [SARACEN], the European Commission, Huawei, or