RFC 7846
Peer-to-Peer Streaming Tracker Protocol (PPSTP)
Pages: 55
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 38 to 55
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 content. 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 HTTP.
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.
The TCP-MIB [RFC4022] can additionally be considered for network monitoring. 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
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 specification. 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 required.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 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 protocol. 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 non-backwards-compatible. 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 distribution.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 |
+--------+ +---------+
| |
|--CONNECT--------------------->|
|<--------------------------OK--|
|--JOIN(swarm_a;SEEDER)---------->|
|<--------------------------OK--|
: :
|--STAT_REPORT(activity)------->|
|<--------------------------Ok--|
: :
|--JOIN(swarm_b;LEECH)--------->|
|<-----------------OK+PeerList--|
: :
|--STAT_REPORT(ChunkMap_b)----->|
|<--------------------------Ok--|
: :
|--DISCONNECT(swarm_b)--------->|
|<--------------------------Ok--|
: :
|--STAT_REPORT(activity)------->|
|<--------------------------Ok--|
: :
|--DISCONNECT------------------>|
|<---------------------Ok(BYE)--|
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 consideration. 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 [RFC7159]. 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 (iesg@ietf.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
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, <http://www.rfc-editor.org/info/rfc2119>. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>. [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, <http://www.rfc-editor.org/info/rfc3986>. [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, <http://www.rfc-editor.org/info/rfc5245>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>. [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, <http://www.rfc-editor.org/info/rfc5590>. [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, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>. [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, <http://www.rfc-editor.org/info/rfc6241>. [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>. [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>. [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, <http://www.rfc-editor.org/info/rfc7230>. [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, <http://www.rfc-editor.org/info/rfc7231>. [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, <http://www.rfc-editor.org/info/rfc7285>. [RFC7574] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to- Peer Streaming Peer Protocol (PPSPP)", RFC 7574, DOI 10.17487/RFC7574, July 2015, <http://www.rfc-editor.org/info/rfc7574>. [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>.
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, <http://www.rfc-editor.org/info/rfc2564>. [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, DOI 10.17487/RFC2790, March 2000, <http://www.rfc-editor.org/info/rfc2790>. [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, DOI 10.17487/RFC2975, October 2000, <http://www.rfc-editor.org/info/rfc2975>. [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, <http://www.rfc-editor.org/info/rfc3410>. [RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, DOI 10.17487/RFC3729, March 2004, <http://www.rfc-editor.org/info/rfc3729>. [RFC4022] Raghunarayan, R., Ed., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, DOI 10.17487/RFC4022, March 2005, <http://www.rfc-editor.org/info/rfc4022>. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>. [RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, DOI 10.17487/RFC4150, August 2005, <http://www.rfc-editor.org/info/rfc4150>.
[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, <http://www.rfc-editor.org/info/rfc5226>. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>. [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <http://www.rfc-editor.org/info/rfc5706>. [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>. [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, <http://www.rfc-editor.org/info/rfc6972>. [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, <http://www.rfc-editor.org/info/rfc7525>. [SARACEN] Sarecen P2P, <http://www.saracen-p2p.eu/>.Acknowledgments
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.
Authors' Addresses
Rui Santos Cruz IST/INESC-ID/INOV Phone: +351.939060939 Email: rui.cruz@ieee.org Mario Serafim Nunes IST/INESC-ID/INOV Rua Alves Redol, n.9 1000-029 Lisboa Portugal Phone: +351.213100256 Email: mario.nunes@inov.pt Jinwei Xia Huawei Nanjing, Baixia District 210001 China Phone: +86-025-86622310 Email: xiajinwei@huawei.com Rachel Huang (editor) Huawei Email: rachel.huang@huawei.com Joao P. Taveira IST/INOV Email: joao.silva@inov.pt Deng Lingli China Mobile Email: denglingli@chinamobile.com