Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   None  Group: PPSP

RFC 7846

Peer-to-Peer Streaming Tracker Protocol (PPSTP)

Pages: 55
Proposed STD
Part 3 of 3 – Pages 38 to 55
First   Prev   None

Top   ToC   Page 38   prevText
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
Top   ToC   Page 39
   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
Top   ToC   Page 40
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.

5.2.1.  Interoperability

   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
   (NETCONF) [RFC6241].

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.
Top   ToC   Page 41
   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
   NETCONF [RFC6241].

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
Top   ToC   Page 42
   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
   the tracker.

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].
Top   ToC   Page 43
   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.
Top   ToC   Page 44
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.
Top   ToC   Page 45
7.  Guidelines for Extending PPSTP

   Extension mechanisms allow designers to add new features or to
   customize existing features of a protocol for different operating
   environments [RFC6709].

   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.
Top   ToC   Page 46
      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
Top   ToC   Page 47
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.
Top   ToC   Page 48
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.

   Additional information:

      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 (
Top   ToC   Page 49
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
Top   ToC   Page 50
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
Top   ToC   Page 51
9.  References

9.1.  Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119,
               DOI 10.17487/RFC2119, March 1997,

   [RFC2818]   Rescorla, E., "HTTP Over TLS", RFC 2818,
               DOI 10.17487/RFC2818, May 2000,

   [RFC3629]   Yergeau, F., "UTF-8, a transformation format of ISO
               10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
               2003, <>.

   [RFC3986]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
               Resource Identifier (URI): Generic Syntax", STD 66, RFC
               3986, DOI 10.17487/RFC3986, January 2005,

   [RFC5245]   Rosenberg, J., "Interactive Connectivity Establishment
               (ICE): A Protocol for Network Address Translator (NAT)
               Traversal for Offer/Answer Protocols", RFC 5245,
               DOI 10.17487/RFC5245, April 2010,

   [RFC5246]   Dierks, T. and E. Rescorla, "The Transport Layer Security
               (TLS) Protocol Version 1.2", RFC 5246,
               DOI 10.17487/RFC5246, August 2008,

   [RFC5389]   Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
               "Session Traversal Utilities for NAT (STUN)", RFC 5389,
               DOI 10.17487/RFC5389, October 2008,

   [RFC5590]   Harrington, D. and J. Schoenwaelder, "Transport Subsystem
               for the Simple Network Management Protocol (SNMP)", STD
               78, RFC 5590, DOI 10.17487/RFC5590, June 2009,

   [RFC5766]   Mahy, R., Matthews, P., and J. Rosenberg, "Traversal
               Using Relays around NAT (TURN): Relay Extensions to
               Session Traversal Utilities for NAT (STUN)", RFC 5766,
               DOI 10.17487/RFC5766, April 2010,
Top   ToC   Page 52
   [RFC5952]   Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
               Address Text Representation", RFC 5952,
               DOI 10.17487/RFC5952, August 2010,

   [RFC6241]   Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J.,
               Ed., and A. Bierman, Ed., "Network Configuration Protocol
               (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,

   [RFC6749]   Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
               RFC 6749, DOI 10.17487/RFC6749, October 2012,

   [RFC7159]   Bray, T., Ed., "The JavaScript Object Notation (JSON)
               Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
               March 2014, <>.

   [RFC7230]   Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
               Transfer Protocol (HTTP/1.1): Message Syntax and
               Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014,

   [RFC7231]   Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
               Transfer Protocol (HTTP/1.1): Semantics and Content", RFC
               7231, DOI 10.17487/RFC7231, June 2014,

   [RFC7285]   Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel,
               S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
               "Application-Layer Traffic Optimization (ALTO) Protocol",
               RFC 7285, DOI 10.17487/RFC7285, September 2014,

   [RFC7574]   Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to-
               Peer Streaming Peer Protocol (PPSPP)", RFC 7574,
               DOI 10.17487/RFC7574, July 2015,

   [RFC7616]   Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
               Digest Access Authentication", RFC 7616,
               DOI 10.17487/RFC7616, September 2015,
Top   ToC   Page 53
9.2.  Informative References

   [Contracts] Piatek, M., Krishnamurthy, A., Venkataramani, A., Yang,
               R., Zhang, D., and A.  Jaffe, "Contracts: Practical
               Contribution Incentives for P2P Live Streaming", NSDI:
               USENIX Symposium on Networked Systems Design and
               Implementation, April 2010.

   [RFC2564]   Kalbfleisch, C., Krupczak, C., Presuhn, R., and J.
               Saperia, "Application Management MIB", RFC 2564,
               DOI 10.17487/RFC2564, May 1999,

   [RFC2790]   Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC
               2790, DOI 10.17487/RFC2790, March 2000,

   [RFC2975]   Aboba, B., Arkko, J., and D. Harrington, "Introduction to
               Accounting Management", RFC 2975, DOI 10.17487/RFC2975,
               October 2000, <>.

   [RFC3410]   Case, J., Mundy, R., Partain, D., and B. Stewart,
               "Introduction and Applicability Statements for Internet-
               Standard Management Framework", RFC 3410,
               DOI 10.17487/RFC3410, December 2002,

   [RFC3729]   Waldbusser, S., "Application Performance Measurement
               MIB", RFC 3729, DOI 10.17487/RFC3729, March 2004,

   [RFC4022]   Raghunarayan, R., Ed., "Management Information Base for
               the Transmission Control Protocol (TCP)", RFC 4022,
               DOI 10.17487/RFC4022, March 2005,

   [RFC4122]   Leach, P., Mealling, M., and R. Salz, "A Universally
               Unique IDentifier (UUID) URN Namespace", RFC 4122,
               DOI 10.17487/RFC4122, July 2005,

   [RFC4150]   Dietz, R. and R. Cole, "Transport Performance Metrics
               MIB", RFC 4150, DOI 10.17487/RFC4150, August 2005,
Top   ToC   Page 54
   [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
               2015, <>.

   [SARACEN]   Sarecen P2P, <>.


   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
   China Mobile.
Top   ToC   Page 55
Authors' Addresses

   Rui Santos Cruz
   Phone: +351.939060939

   Mario Serafim Nunes
   Rua Alves Redol, n.9
   1000-029 Lisboa
   Phone: +351.213100256

   Jinwei Xia
   Nanjing, Baixia District 210001
   Phone: +86-025-86622310

   Rachel Huang (editor)

   Joao P. Taveira

   Deng Lingli
   China Mobile