RFC 7846
Peer-to-Peer Streaming Tracker Protocol (PPSTP)
RFC 7846: Peer-to-Peer Streaming Tracker Protocol (PPSTP) 🎀
okay so this is the spec for the Peer-to-Peer Streaming Tracker Protocol (PPSTP), and it's giving serious standards-track energy ✨ It's written by R. Cruz, M. Nunes, J. Xia, R. Huang (Ed.), J. Taveira, and D. Lingli, from IST/INESC-ID/INOV, Huawei, IST/INOV, and China Mobile. It was published in May 2016 and is a Standards Track document (ISSN 2070-1721). The header doesn't list any RFC that it obsoletes or updates, so it's a fresh start 🌸
Abstract
okay so this doc defines the base Peer-to-Peer Streaming Tracker Protocol (PPSTP) version 1 💖 it's an application-layer control (signaling) protocol for trading meta information between trackers and peers. The spec covers the architecture, message flows, message processing instructions, message formats, formal syntax, and semantics. PPSTP lets cooperating peers form content-streaming overlay networks so structured media (audio, video, and associated timed text and metadata) can be delivered in near real-time. That includes adaptive multi-rate, layered (scalable), and multi-view (3D) videos in live, time-shifted, and on-demand modes 🎬🔥
Status of This Memo
this is an Internet Standards Track document 🧚
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7846 🔗
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they were on the publication date. You can find them at http://trustee.ietf.org/license-info. Please read these carefully, because they explain your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License.
Table of Contents 📚
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Design Overview ............................................6
1.2.1. Typical PPSP Session ................................7
1.2.2. Example of a PPSP Session ...........................7
2. Protocol Architecture and Functional View ......................10
2.1. Messaging Model ...........................................10
2.2. Request/Response Model ....................................10
2.3. State Machines and Flows of the Protocol ..................12
2.3.1. Normal Operation ...................................14
2.3.2. Error Conditions ...................................15
3. Protocol Specification .........................................16
3.1. Presentation Language .....................................16
3.2. Resource Element Types ....................................16
3.2.1. Version ............................................16
3.2.2. Peer Number Element ................................17
3.2.3. Swarm Action Element ...............................18
3.2.4. Peer Information Elements ..........................18
3.2.5. Statistics and Status Information Element ..........20
3.3. Requests and Responses ....................................21
3.3.1. Request Types ......................................21
3.3.2. Response Types .....................................21
3.3.3. Request Element ....................................22
3.3.4. Response Element ...................................23
3.4. PPSTP Message Element .....................................24
4. Protocol Specification: Encoding and Operation .................24
4.1. Requests and Responses ....................................25
4.1.1. CONNECT Request ....................................25
4.1.1.1. Example ...................................28
4.1.2. FIND Request .......................................32
4.1.2.1. Example ...................................33
4.1.3. STAT_REPORT Request ................................34
4.1.3.1. Example ...................................35
4.2. Response Element in Response Messages .....................36
4.3. Error and Recovery Conditions .............................37
4.4. Parsing of Unknown Fields in message-body .................38
5. Operations and Manageability ...................................38
5.1. Operational Considerations ................................38
5.1.1. Installation and Initial Setup .....................38
5.1.2. Migration Path .....................................39
5.1.3. Requirements on Other Protocols and
Functional Components ..............................39
5.1.4. Impact on Network Operation ........................39
5.1.5. Verifying Correct Operation ........................40
5.2. Management Considerations .................................40
5.2.1. Interoperability ...................................40
5.2.2. Management Information .............................40
5.2.3. Fault Management ...................................41
5.2.4. Configuration Management ...........................41
5.2.5. Accounting Management ..............................41
5.2.6. Performance Management .............................41
5.2.7. Security Management ................................41
6. Security Considerations ........................................42
6.1. Authentication between Tracker and Peers ..................42
6.2. Content Integrity Protection against Polluting
Peers/Trackers ............................................43
6.3. Residual Attacks and Mitigation ...........................43
6.4. Pro-incentive Parameter Trustfulness ......................44
6.5. Privacy for Peers .........................................44
7. Guidelines for Extending PPSTP .................................45
7.1. Forms of PPSTP Extension ..................................45
7.2. Issues to Be Addressed in PPSTP Extensions ................47
8. IANA Considerations ............................................48
8.1. MIME Type Registry ........................................48
8.2. PPSTP Version Number Registry .............................49
8.3. PPSTP Request Type Registry ...............................49
8.4. PPSTP Error Code Registry .................................50
9. References .....................................................51
9.1. Normative References ......................................51
9.2. Informative References ....................................53
Acknowledgments ...................................................54
Authors' Addresses ................................................551. Introduction ✨
the Peer-to-Peer Streaming Protocol (PPSP) is made of two protocols 💅 One is the Tracker Protocol (the one this doc defines), and the other is the Peer Protocol (defined in [RFC7574]). [RFC6972] says the Tracker Protocol should standardize the messages between PPSP peers and PPSP trackers, and it also sets out the requirements 🎀
PPSTP is the piece that lets trackers and peers talk to each other. Peers use it to send meta information to trackers, report their streaming status, and grab peer lists from trackers 🦋
The PPSP architecture needs PPSP peers to be able to talk to a tracker so they can join a particular streaming content swarm. This centralized tracker service is how PPSP peers get their peer lists 🧚
The signaling and the media data transfer between PPSP peers are out of scope for this spec so we're not covering them here 🙈
This document introduces a base Peer-to-Peer Streaming Tracker Protocol (PPSTP) that satisfies the requirements in [RFC6972]. It's giving exactly what the requirements asked for 👑
1.1. 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 [RFC2119].
Okay bestie, here's the vocab list we're using all through this doc 💅 Read this first, it's the foundation for everything else 🫶
- absolute time: Written as ISO 8601 timestamps with a zero UTC offset ⏰ Fractions of a second are allowed too. For example, December 25, 2010 at 14h56 and 20.25 seconds is
20101225T145620.25Zin basic format and2010-12-25T14:56:20.25Zin extended format 🎀 - chunk: A uniformly atomic subset of the resource 🧩 It's the basic unit of data in P2P streaming, used for storage, scheduling, advertisement, and exchange among peers 💖
- chunk ID: A unique resource identifier for a chunk 🔖 Its type depends on the addressing scheme, i.e., an integer, an HTTP-URL, and possibly a byte-range. The identifier type is described in the Media Presentation Description (MPD) 📜
- LEECH: Peers in a swarm that download content from other peers and also contribute downloaded content with others 📥 A LEECH should join the swarm with uncompleted media content.
- MPD (Media Presentation Description): The formalized description of a media presentation 🎬 It describes the structure of the media, namely the representations, the codecs used, the chunks, and the corresponding addressing scheme 🧠
- peer: A participant in a P2P streaming system that not only receives streaming content, but also caches and streams it to other participants 🦋
- peer ID: The identifier of a peer, so other peers (or the Tracker) can refer to it 🪪 The peer ID is mandatory 👑 It can take the form of a universally unique identifier (UUID), defined in [RFC4122], and can be bound to a network address of the peer, i.e., an IP address or a uniform resource identifier/locator (URI/URL) that uniquely identifies the corresponding peer in the network 🌐 The peer ID and any required security certificates are obtained from an offline enrollment server 🔐
- peer list: A list of peers in the same swarm, maintained by the tracker 📋 A peer can fetch the peer list of a swarm from the tracker ✨
- PPSP: Short for Peer-to-Peer Streaming Protocol 🌸
- PPSTP: Short for Peer-to-Peer Streaming Tracker Protocol 🧚
- SEEDER: Peers in a swarm that only contribute the content they have to others 🌱 A SEEDER should join the swarm with complete media content.
- service portal: A logical entity typically used for client enrollment and for publishing, searching, and retrieving content information 💌 It's usually located in a server of a content provider 🏢
- swarm: A group of peers that exchange data to distribute chunks of the same content (e.g., video/audio program, digital file, etc.) at a given time 🐝
- swarm ID: The identifier of a swarm, which contains a group of peers sharing common streaming content 🏷️ The swarm ID may use a universally unique identifier (UUID), e.g., a 64- or 128-bit datum, to refer to the content resource being shared among peers 💜
- tracker: A directory service that maintains a list of peers participating in a specific audio/video channel or in the distribution of a streaming file 🗂️ It's a logical component that can be deployed in a centralized or distributed way 🌈
- transaction ID: The identifier of a request from the peer to the tracker 🎟️ It's used to disambiguate responses that may arrive in a different order than the corresponding requests 🙈
1.2. Design Overview 🧁
Okay so the main players in P2P streaming are the Client Media Player, the service portal, the tracker, and the peers 💖 Heads up though: the complete description of the Client Media Player and service portal isn't covered here, since they're not in the scope of the specification 🙅♀️ The functional entities directly involved in PPSTP are trackers and peers (which may support different capabilities) ✨
The Client Media Player is a logical entity that gives the end user a direct interface on the client device 🎥 It includes the functions to select, request, decode, and render content 🖼️ The Client Media Player may interface with the local peer application using the standard format for HTTP request and response messages [RFC7230] 🔁
The service portal is a logical entity typically used for client enrollment and for publishing, searching, and retrieving content information 💌
A peer is a logical entity (typically living in a user device) that actually participates in sharing media content 🦋 Peers are organized into various swarms, and each swarm corresponds to the group of peers streaming certain content at any given time 🐝
A tracker is a logical entity that maintains the lists of peers storing chunks for a specific live media channel or for on-demand media streaming content 🗃️ It answers queries from peers and collects information on the activity of peers 📊 A tracker may have an underlying implementation made up of more than one physical node, but logically, it's most simple to think of the tracker as a single element 🧠 So in this document, it's treated as a single logical entity 🎀 Communication between those physical nodes to present them as one tracker to peers is not considered in PPSTP, which is a protocol between a tracker and a peer 🤫
PPSTP is not used to exchange actual content data (either on demand or live streaming) with peers 🚫 It's used for information about which peers can provide the content 📡 PPSTP is not designed for applications for which in-sync reception is needed ⏳
1.2.1. Typical PPSP Session 🎬
Here's the flow when a peer wants to receive streaming of selected content (LEECH mode) 📥
- Peer connects to a tracker and joins a swarm.
- Peer acquires a list of other peers in the swarm from the tracker.
- Peer exchanges its content availability with the peers on the obtained peer list.
- Peer identifies the peers with desired content.
- Peer requests content from the identified peers.
And when a peer wants to share streaming content (SEEDER mode) with other peers 🌱
- Peer connects to a tracker.
- Peer sends information to the tracker about the swarms it belongs to (joined swarms).
- Peer waits for other peers in LEECH mode to connect with it (see steps 3-5 in the previous list).
After being disconnected due to some termination conditions or user controls, a peer can resume its previous activity by connecting and re-joining the corresponding swarm(s) 🔄✨
1.2.2. Example of a PPSP Session 🎬✨
okay so bestie, before a peer can even bootstrap into the P2P network, it needs a peer ID plus any security certificates or authorization tokens from an enrollment service (that's the end-user registration bit) 🫶. The peer ID MUST be unique (check the "peer ID" definition in Section 1.1 🔑), but how you represent it isn't covered in this document 💅.
+--------+ +--------+ +--------+ +---------+ +--------+
| Player | | Peer_1 | | Portal | | Tracker | | Peer_2 |
+--------+ +--------+ +--------+ +---------+ +--------+
| | | | |
(a) |--Page request----------------->| | |
|<--------------Page with links--| | |
|--Select stream (MPD request)-->| | |
|<--------------------OK+MPD(x)--| | |
(b) |--Start/Resume->|--CONNECT(join x)------------>| |
|<-----------OK--|<----------------OK+Peerlist--| |
| | | |
|--Get(chunk)--->|<---------- (Peer protocol) ------------->|
|<--------chunk--|<---------------------------------chunks--|
: : : : :
| |--STAT_REPORT---------------->| |
| |<-------------------------OK--| |
: : : : :
| |--FIND----------------------->| |
| |<----------------OK+Peerlist--| |
: : : : :
|--Get(chunk)--->|<---------- (Peer protocol) ------------->|
|<--------chunk--|<---------------------------------chunks--|
: : : : :
Figure 1: A Typical PPSP Session for Streaming Contentso to join an existing P2P streaming service and actually share content 🌸, a peer has to find a tracker first. Totally non-negotiable 😭.
Look at Figure 1 and you'll see a streaming session can kick off at point (a), where the Client Media Player is browsing for something to watch and requests it from the local Peer_1 🍿. Or it can pick up a stream you already started at point (b) 🔁. For this example, Peer_1 is in mode LEECH 🦋.
At point (a), the Client Media Player hits the portal and picks the content it's obsessed with 💖. The portal sends back the Media Presentation Description (MPD) file, which has the address of one or more trackers (they can be grouped by tiers of priority 👑) that run the swarm x for that media content (e.g., content x) ✨.
With the info from the MPD, the Client Media Player can finally start the streaming session by asking the local Peer_1 for the chunks it wants 🎀.
The PPSP streaming session then starts (or resumes) at Peer_1 when it sends a PPSTP CONNECT message to the tracker to join swarm x 🚀. If the CONNECT message gets accepted, the tracker sends back an OK response with a peer list 📋. From that point on, every chunk request goes from Peer_1 to its neighbors (Peer_2 in Figure 1) over a peer protocol, e.g., [RFC7574] 🧚, and the chunks come back to the Client Media Player 🫧.
Once connected, Peer_1 has to keep reporting its status and stats to the tracker with a STAT_REPORT message 📊. It's giving "check in regularly" energy 💅.
If Peer_1 needs a fresh neighborhood (say, because of churn 🌪️), it sends a PPSTP FIND message to the tracker with the scope it wants 🔍.
Now, peers that are only SEEDERs (they just serve content to other peers), like service provider P2P edge caches and media servers 🖥️, are a different vibe. They don't start streams from Media Player signals. Instead, they get a "Start" activation signal from the service provider's provisioning mechanism 🚦. So a SEEDER starts or resumes all its streaming sessions (content x, y, z...) by sending one PPSTP CONNECT message to the tracker (Figure 2) to "join" all the requested swarms 🧃. Lowkey so efficient 🙌.
Periodically, the peer also sends a PPSTP STAT_REPORT message to the tracker with its status and stats 🔄.
+---------+ +---------+
| SEEDER | | Tracker |
+---------+ +---------+
| |
Start->|--CONNECT (join x,y,z)-------->|
|<--------------------------OK--|
: :
| |
|--STAT_REPORT----------------->|
|<--------------------------Ok--|
: :
| |
|--STAT_REPORT----------------->|
|<--------------------------Ok--|
: :
Figure 2: A Typical PPSP Session for a Streaming SEEDERAnd the mechanisms for the Client Media Player (or provisioning process) and the peer to signal start/resume of streams, request media chunks, and get a peer ID, security certificates, or tokens? Not in scope for this document 🙈. Not my job, bestie 💀.
2. Protocol Architecture and Functional View 🏗️
PPSTP is designed with a layered approach, i.e., a PPSTP Request/Response layer, a Message layer, and a Transport layer (see Figure 3) 🎂.
+------------------------+
| Application |
+------------------------+
|(PPSTP) Request/Response|
|------------------------|
| (HTTP) Message |
+------------------------+
| Transport |
+------------------------+
Figure 3: Abstract Layering of PPSTPThe PPSTP Request/Response layer handles the back-and-forth between tracker and peers using request and response messages 💬.
The Message layer handles the framing format for encoding and sending data through the underlying transport protocol, plus the asynchronous nature of tracker-peer interactions 🧵.
The Transport layer is in charge of actually sending requests and responses over network transports, including figuring out which connection to use for a request or response message when TCP or Transport Layer Security (TLS) [RFC5246] is running over it 🔌.
2.1. Messaging Model 📨
The messaging model of PPSTP lines up with HTTP, currently version 1.1 [RFC7230], and the semantics of its messages 🤝. PPSTP is meant to support future versions of HTTP too 🔮.
2.2. Request/Response Model 🔁
PPSTP uses a design like REST (Representational State Transfer) so it can build on current HTTP implementations and infrastructure, plus the familiarity of REST-like services people already use 💖. PPSTP messages use the UTF-8 character set [RFC3629] and are either requests from peers to a tracker service or responses from a tracker service to peers 🌈. The request and response semantics are carried as entities (header and body) in messages that match either HTTP request methods or HTTP response codes, respectively 🧩.
PPSTP uses the HTTP POST method to send parameters in requests 📬. PPSTP messages use JavaScript Object Notation (JSON) [RFC7159] to encode message bodies 🍓.
Peers send requests to trackers. Trackers send a single response for each request, though both requests and responses can be fragmented in transport 🧃.
The request messages of the base protocol are listed in Table 1 📋:
+------------------------------+
| PPSTP Request Messages |
+------------------------------+
| CONNECT |
| FIND |
| STAT_REPORT |
+------------------------------+
Table 1: Request MessagesCONNECT: This request message is used when a peer registers in the tracker to tell it about participation in the named swarm(s). If the peer is already registered, this request message just tells the tracker about participation in the named swarm(s) 🔗. The tracker records the peer ID, connect-time (referenced to the absolute time), peer IP addresses (and associated location information), link status, and peer mode for the named swarm(s) 🗂️. It also changes the content availability of the valid named swarm(s), i.e., it changes the lists of the corresponding swarm(s) for the requesting peer ID 🔄. On receiving a CONNECT message, the tracker first checks the peer mode type (SEEDER/LEECH) for the specified swarm(s) and then decides the next steps (see Section 4.1 for more details) 🕵️.
FIND: This request message is used by peers to ask the tracker for a list of peers active in the named swarm whenever they need one 🙋. On receiving a FIND message, the tracker finds the peers listed in the content status of the specified swarm that can satisfy the requesting peer's requirements and returns the list to the requesting peer 🎯. To create the peer list, the tracker may take peer status, capabilities, and peer priority into consideration ⚖️. Peer priority may be determined by network topology preference, operator policy preference, etc. 🌐
STAT_REPORT: This request message is used to let an active peer send status (and optionally statistic data) to the tracker to signal continuing activity 💓. This request message MUST be sent periodically to the tracker while the peer is active in the system ⏰🫶.
2.3. State Machines and Flows of the Protocol ✨
Okay, the tracker's state machine is honestly so simple it's giving minimalism 🤍 (Figure 4). The thing that's actually dynamic is the Peer ID registrations, since the network is constantly keeping track of them 🦋
--------------------------------------------
/ \
| +------------+ +=========+ +======+ |
\-| TERMINATED |<---| STARTED |<---| INIT |<-/
+------------+ +=========+ +======+
(Transient) \- (start tracker)
Figure 4: Tracker State MachineWhen there are no peers connected to the tracker, it's chillin' in the INIT state 😴
When the first peer shows up and registers its peer ID, the state machine hops from INIT to STARTED 🚀 It stays in STARTED for as long as there's at least one active peer ID registration. Once the last peer ID gets removed, it moves to TERMINATED, but it immediately bounces right back to INIT. So yeah, TERMINATED is super transient 💨
Once the tracker is in STARTED, each peer (per peer ID) gets its very own "per-Peer-ID" state machine running inside the tracker, paired with a dedicated transaction state machine (Figure 5). That one gets deleted when its peer ID is removed 🧹
--------------------------------------------
/ \
| +------------+ +=========+ +======+ |
\-| TERMINATED |<---| STARTED |<---| INIT |<-/
+------------+ +=========+ +======+
(Transient) | (1) \- (start tracker)
V
+-----------+ +-------+ rcv CONNECT
(Transient) | TERMINATE | | START | --------------- (1)
+-----------+ +-------+ strt init timer
rcv FIND (B) ^ |
rcv STAT_REPORT (B) | |
on registration error (B)| v
on action error (A) | +------------+
---------------- +<--| PEER | (Transient)
stop init timer | | REGISTERED |
snd error | +------------+
| |
on timeout (D) | | process swarm actions
---------------- | | --------------------- (2)
stop track timer | | snd OK (PeerList)
clean peer info | / stop init timer
del registration | / strt track timer
| /
| |
| | rcv FIND
STAT_REPORT ERR(C) \ | ---- --------------- (3)
FIND ERR(C) ---- \ | / \ snd OK (PeerList)
CONNECT ERR(C) / \ | | | | rst track timer
rcv CONNECT | (4) | | | | |
----------- | v | v v | rcv STAT_REPORT
snd OK \ +==============+ / --------------- (3)
rst track timer ----| TRACKING |---- snd OK response
snd error (C) +==============+ rst track timer
Figure 5: "Per-Peer-ID" State Machine and Flow DiagramOkay, this one's the real main character 🎀 Unlike the tracker machine (which hangs around even when no peer IDs are registered), the "per-Peer-ID" State Machine only shows up once a peer ID starts registering in the tracker, and it's deleted when that peer ID is de-registered or removed. This also means the tracker can destroy those objects as soon as the machine enters the TERMINATE state (Figure 5), which is a nice implementation shortcut 💅
When a brand-new peer ID gets added, its "per-Peer-ID" State Machine is created and immediately moves into PEER REGISTERED. So the START state is only transient 🌸
When the peer ID isn't tied to a registration anymore, the machine goes to TERMINATE and gets destroyed. Bye bye 👋
While a peer is streaming, its instantiated "per-Peer-ID" State Machine keeps moving between states depending on events. The events that can move it along are:
- Reception of CONNECT, FIND, and STAT_REPORT messages
- Timeout events
Figure 5 shows the state changes along with the events that cause them and the actions that result. Specific error conditions aren't drawn in the diagram, so we'll cover those in the next bit 🙈
2.3.1. Normal Operation
Here's how the happy path goes 🥰
- When a peer wants in, it has to register with a tracker by sending a CONNECT message asking for the swarm(s) it wants to join. That request from a new peer ID kicks off a brand-new "per-Peer-ID" State Machine in the tracker. In the START state of that new machine, the tracker registers the peer ID and its associated information (IP addresses), starts the "init timer", and moves to PEER REGISTERED state.
- In PEER REGISTERED state, if the peer ID is valid, the tracker does one of two things:
- a) It processes the requested action(s) for the valid swarm information in the CONNECT requests. If that works out, the tracker stops the "init timer", starts the "track timer", and sends the response to the peer. The response may contain the right list of peers for the joining swarm(s), as detailed in Section 4.1.
- b) It moves the valid FIND request into TRACKING state.
- In TRACKING state, STAT_REPORT or FIND messages from that peer ID reset the "track timer", and the tracker answers them with the following, respectively:
- a) a successful condition, or
- b) a successful condition containing the appropriate list of peers for the named swarm (Section 4.2).
- While in TRACKING state, a CONNECT message from that peer ID with valid swarm action information (Section 4.1.1) resets the "track timer", and the tracker responds to it with a successful condition.
2.3.2. Error Conditions
Peers are required not to generate protocol elements that are invalid. Still, a few situations can cause things to go sideways when talking to the tracker 😬 These might come from a peer malfunctioning or from communication errors. The tracker reacts to these abnormal situations based on what state it's in for that peer ID, like this:
A) In PEER REGISTERED state, when a CONNECT request only contains invalid swarm actions (Section 4.1.1), the tracker responds with a PPSTP error code as specified in Section 4.3, deletes the registration, and transitions to TERMINATE state for that peer ID. The state machine is destroyed. 💀
B) In PEER REGISTERED state, if the peer ID is considered invalid (either in the case of a CONNECT request, or in the case of FIND or STAT_REPORT requests received from an unregistered peer ID), the tracker responds with either a 06 (Authentication Required) error_code or a 03 (Forbidden Action) error_code, as described in Section 4.3, and transitions to TERMINATE state for that peer ID. The state machine is destroyed.
C) In TRACKING state (while the "track timer" hasn't expired), receiving a CONNECT message from a peer ID with invalid swarm actions (Section 4.1.1), or receiving a FIND/STAT_REPORT message from a peer ID with an invalid swarm ID, counts as an error condition. The tracker responds with the matching error code (described in Section 4.3).
D) In TRACKING state, if no messages arrive from the peer and the "track timer" expires, the tracker cleans up all the information associated with that peer ID in every swarm it had joined, deletes the registration, and transitions to TERMINATE state for that peer ID. The state machine is destroyed. 👋
NOTE: These situations may correspond to malfunctions at the peer or to malicious conditions. As a preventive measure, the tracker proceeds to TERMINATE state for that peer ID. 🚨
3. Protocol Specification 📜
3.1. Presentation Language
PPSTP uses a REST-like design, and it encodes its requests and responses using JSON [RFC7159]. To describe protocol elements and fields in general (including their types and structures), this document uses a C-style notation, which is similar to the presentation language used to define TLS [RFC5246] 🧠
A JSON object is made of name/value pairs, following the grammar specified in [RFC7159]. In this document, comments begin with "//", and the "ppsp_tp_string_t" and "ppsp_tp_integer_t" types stand for the JSON string and number, respectively. Optional fields are wrapped in "[ ]" brackets. An array is written as two numbers in angle brackets, <min..max>, where "min" is the minimum number of values and "max" is the maximum. A "*" means there's no upper bound on "max" ♾️
3.2. Resource Element Types
This section lays out the format of PPSTP resource element types 🎀
3.2.1. Version
For both requests and responses, the version of PPSTP in use MUST be indicated by the attribute version, which is defined like this 💖
ppsp_tp_integer_t ppsp_tp_version_t = 1The defined value for ppsp_tp_version_t is listed in Table 2.
+----------------------------------------------------------+
| ppsp_tp_version_t | Description |
+----------------------------------------------------------+
| 0 | Reserved |
| 1 | PPSTP version 1 |
| 2-255 | Unassigned |
+----------------------------------------------------------+
Table 2: PPSTP Version Numbers3.2.2. Peer Number Element
The peer number element is a scope selector that can optionally show up in CONNECT and FIND requests 🦋
This element holds the attribute peer_count, which tells the tracker the maximum number of peers to put in the returned peer list. In this specification, peer_count should be less than 30 🌈 The other four attributes (ability_nat, concurrent_links, online_time, and upload_bandwidth) can also live in this element. They help the tracker understand the peer's status, so it can return some eligible peers based on the rules the service providers set up 🧚
- ability_nat is used to indicate the preferred NAT traversal situation of the requesting peer.
- concurrent_links means the number of P2P links the peer currently has.
- online_time represents the online duration of the peer. The unit is second.
- upload_bandwidth is the maximum upload bandwidth capability of the peer. The unit is Kbps.
Here's the scope selector element and its attributes, defined like so ✨
Object {
ppsp_tp_integer_t peer_count;
[ppsp_tp_string_t ability_nat = "NO_NAT"
| "STUN"
| "TURN";]
[ppsp_tp_integer_t concurrent_links;]
[ppsp_tp_integer_t online_time;]
[ppsp_tp_integer_t upload_bandwidth;]
} ppsp_tp_peer_num_t;3.2.3. Swarm Action Element ✨
okay so the swarm action element is the one that tells the peer what to do in the named swarm(s) 🫶 it covers the action (JOIN or LEAVE) and the peer mode (LEECH or SEEDER) if the peer is in that swarm 🦋
Object {
ppsp_tp_string_t swarm_id; //swarm ID
ppsp_tp_string_t action = "JOIN"
|"LEAVE"; // Action type of
// the CONNECT
// message
ppsp_tp_string_t peer_mode = "SEEDER"
| "LEECH"; // Mode of the peer
// participating
// in this swarm
} ppsp_tp_swarm_action_t;3.2.4. Peer Information Elements 💜
the peer information elements are the network ID stuff for peers 🌸 each one is a peer identifier plus the IP-related addressing info, so you know exactly where to find them 🗺️
Object {
ppsp_tp_string_t peer_id;
ppsp_tp_peer_addr_t peer_addr;
} ppsp_tp_peer_info_t;the ppsp_tp_peer_addr_t element has the IP address and port, plus a few optional extras: connection type, network location (as an ASN), and the identifier of the peer protocol being used if there is one ✨
Object {
ppsp_tp_ip_address ip_address;
ppsp_tp_integer_t port;
ppsp_tp_integer_t priority;
ppsp_tp_string_t type = "HOST"
| "REFLEXIVE"
| "PROXY";
[ppsp_tp_string_t connection = "wireless"
| "wired";]
[ppsp_tp_string_t asn;]
[ppsp_tp_string_t peer_protocol;]
} ppsp_tp_peer_addr_t;here's the breakdown of what each ppsp_tp_peer_addr_t attribute means 📋
+----------------------+----------------------------------+
| Element or Attribute | Description |
+----------------------+----------------------------------+
| ip_address | IP address information |
| port | IP service port value |
| priority | The priority of this interface. |
| | It may be determined by network |
| | topology preference, operator |
| | policy preference, etc. How to |
| | create a priority is outside of |
| | the scope. The larger the value,|
| | the higher the priority. |
| type | Describes the address for NAT |
| | traversal, which can be HOST |
| | REFLEXIVE or PROXY |
| connection | Access type (wireless or wired) |
| asn | Autonomous System Number |
| peer_protocol | Peer-to-Peer Streaming Peer |
| | Protocol (PPSPP) supported |
+----------------------+----------------------------------+
Table 3: Semantics of ppsp_tp_peer_addr_tso the IP address is written as ppsp_tp_addr_value in this doc 💅 and what it looks like depends on the address_type:
- the IPv4 address is encoded as specified by the "IPv4address" rule in Section 3.2.2 of [RFC3986] 🧠
- the IPv6 address is encoded as specified in Section 4 of [RFC5952] 🌈
Object {
ppsp_tp_string_t address_type;
ppsp_tp_addr_value address;
} ppsp_tp_ip_address;and the peer info in responses gets grouped into a ppsp_tp_peer_group_t element 🎀
Object {
ppsp_tp_peer_info_t peer_info<1..*>;
} ppsp_tp_peer_group_t;3.2.5. Statistics and Status Information Element 📊
the statistics element (stat) describes a bunch of properties about the P2P network 🌈 these can be stream stats or peer status info. each stat element matches one property type, and a single STAT_REPORT message can carry several stat blocks, covering some or all of the swarms the peer is actively in 🦋 this spec only defines the property type "STREAM_STATS", so that's the one we're working with 💖
here's the definition of the statistic element and its attributes 🧁
Object {
ppsp_tp_string_t swarm_id;
ppsp_tp_integer_t uploaded_bytes;
ppsp_tp_integer_t downloaded_bytes;
ppsp_tp_integer_t available_bandwidth;
ppsp_tp_integer_t concurrent_links;
} stream_stats;and what each stream_stats attribute means 👀
+----------------------+----------------------------------+
| Element or Attribute | Description |
+----------------------+----------------------------------+
| swarm_id | Swarm ID |
| uploaded_bytes | Bytes sent to swarm |
| downloaded_bytes | Bytes received from swarm |
| available_bandwidth | Available instantaneous upload |
| | bandwidth |
| concurrent_links | Number of concurrent links |
+----------------------+----------------------------------+
Table 4: Semantics of stream_statsthe stat info gets grouped into the ppsp_tp_stat_group_t element 🫧
Object {
ppsp_tp_string_t type = "STREAM_STATS"; // property type
stream_stats stat<1..*>;
} ppsp_tp_stat_group_tother properties can be defined later too, like ones tied to incentives and reputation mechanisms ("peer online time") or connectivity conditions ("link status", etc.) 🎮
the stat element can be extended with extra info for new properties, elements, or attributes. check the guidelines in Section 7 if you're going that route 🔥
3.3. Requests and Responses 🎀
this section is all about the structure of PPSTP requests and responses 💌
3.3.1. Request Types 🦋
the request type covers CONNECT, FIND, and STAT_REPORT, and it's defined like this 💅
ppsp_tp_string_t ppsp_tp_request_type_t = "CONNECT"
| "FIND"
| "STAT_REPORT";3.3.2. Response Types ✨
the response type matches the response method type of the message 🌸 it's defined like this:
JSONValue ppsp_tp_response_type_t = 0x00 // SUCCESSFUL
| 0x01; // FAILED3.3.3. Request Element 💜
okay this one's important: the request element MUST be present in requests, and it corresponds to the request method type for the message 🚨
here's the generic definition of a request element:
Object {
[ppsp_tp_peer_num_t peer_num;]
[ppsp_tp_peer_addr_t peer_addr<1..*>;]
ppsp_tp_swarm_action_t swarm_action<1..*>;
} ppsp_tp_request_connect;
Object {
ppsp_tp_string_t swarm_id;
[ppsp_tp_peer_num_t peer_num;]
} ppsp_tp_request_find;
Object {
ppsp_tp_version_t version;
ppsp_tp_request_type_t request_type;
ppsp_tp_string_t transaction_id;
ppsp_tp_string_t peer_id;
JSONValue request_data = ppsp_tp_req_connect connect
| ppsp_tp_req_find find
| ppsp_tp_stat_group_t stat_report;
} ppsp_tp_request;so a request element is made of the PPSTP version, the request type, a transaction ID, the requesting peer ID, and the request body (aka request_data) 🫶 the request_data MUST be set correctly to the matching element for the request type. check Table 5 for the pairings 👑
+----------------------+----------------------+
| request_type | request_data |
+----------------------+----------------------+
| "CONNECT" | "connect" |
| "FIND" | "find" |
| "STAT_REPORT" | "stat_report" |
+----------------------+----------------------+
Table 5: The Relationship between request_type and request_data3.3.4. Response Element 🧚
here's the generic definition of a response element 📜
Object {
ppsp_tp_version_t version;
ppsp_tp_response_type_t response_type;
ppsp_tp_integer_t error_code;
ppsp_tp_string_t transaction_id;
[ppsp_tp_peer_addr_t peer_addr;]
[ppsp_tp_swarm_action_result_t swarm_result<1..*>;]
} ppsp_tp_response;a response element has the PPSTP version, the response type, the error code, a transaction ID, and optionally the public address of the requesting peer plus one or more swarm action result elements 🌈 normally, swarm action result elements SHOULD be present, and error_code MUST be set to 00 (No Error) when response_type is 0x00 ✅ swarm action result elements SHOULD NOT be set when error_code is 01 (Bad Request) 🙈 the detailed picking of error_code is in Section 4.3 💅
Object {
ppsp_tp_string_t swarm_id;
ppsp_tp_response_type_t result;
[ppsp_tp_peer_group_t peer_group;]
} ppsp_tp_swarm_action_result_t;a swarm action result element is the result of an action the peer asked for 🔥 it has a swarm identifier that globally points at the swarm, the result for the peer (which could be CONNECT ("JOIN" or "LEAVE"), FIND, or STAT_REPORT), and optionally one peer group element 🦋 the result attribute says whether the operation worked. when the response is for a STAT_REPORT request, or when result is 0x01, the peer group element SHOULD NOT be set 💀
3.4. PPSTP Message Element 💖
PPSTP messages (requests or responses) are designed to look pretty similar, with a root field named "PPSPTrackerProtocol" holding the meta info and data for a request or a response 🎀
the base type of a PPSTP message looks like this 🌟
Object {
JSONValue PPSPTrackerProtocol = ppsp_tp_request Request
| ppsp_tp_response Response;
} ppsp_tp_message_root;4. Protocol Specification: Encoding and Operation ✨
okay bestie, PPSTP is a message-oriented request/response protocol 💖 Its messages use a text encoding in JSON [RFC7159], which MUST be indicated in the Content-Type field in HTTP/1.1 [RFC7231]. You use the "application/ppsp-tracker+json" media type for all PPSTP request parameters and responses 🎀
Implementations MUST support the https URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. No cap, this part is non-negotiable 🔥
For deployment scenarios where peer (client) authentication is desired at the tracker, HTTP Digest Access Authentication [RFC7616] MUST be supported, with TLS Client Authentication as the preferred mechanism, if available 🔐
PPSTP uses the HTTP POST method to send parameters in requests, so it can provide information resources that depend on one or more of those input parameters. The input parameters are encoded in JSON in the HTTP entity body of the request 🧚
This section covers how the three types of PPSTP requests operate, plus a few usage examples 🌈
4.1. Requests and Responses
4.1.1. CONNECT Request
This method is used when a peer registers with the system and/or requests some swarm actions (join/leave) 🦋 The peer MUST properly set the request type to CONNECT, generate and set the transaction_ids, set the peer_id, and include the swarms the peer is interested in, followed by the corresponding action type and peer mode. Main character energy 👑
- When a peer already possesses content and agrees to share it with others, it should set the action type to the value
JOIN, as well as set the peer mode toSEEDERduring its start (or re-start) period 🌱 - When a peer wants to join a swarm to consume content, it should set the action type to the value
JOIN, as well as set the peer mode toLEECHduring its start (or re-start) period 📥
In the cases above, the peer can provide optional information on the addresses of its network interface(s), for example the priority, type, connection, and ASN 🫶
When a peer plans to leave a previously joined swarm, it should set the action type to LEAVE, regardless of the peer mode 🚪
When the tracker receives a well-formed CONNECT request message, it starts by pre-processing the peer authentication information (provided as authorization scheme and token in the HTTP message) to check whether it is valid and that the peer can connect to the service. Then it registers the peer in the service and performs the requested swarm actions. If that works, a response message with a corresponding response value of SUCCESSFUL gets generated ✅
The valid combinations of swarm count, action type, and peer mode for CONNECT request logic are listed in Table 6 (this refers to the "per-Peer-ID" State Machine in Section 2.3). It's giving spreadsheet energy 📊
+-----------+-----------+---------+----------+-----------+----------+
| Swarm | peer_mode | action | Initial | Final | Request |
| Number | Value | Value | State | State | Validity |
+-----------+-----------+---------+----------+-----------+----------|
| 1 | LEECH | JOIN | START | TRACKING | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | LEAVE | START | TERMINATE | Invalid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | LEAVE | TRACKING | TERMINATE | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | JOIN | START | TERMINATE | Invalid |
| 1 | LEECH | LEAVE | | | |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | JOIN | TRACKING | TRACKING | Valid |
| 1 | LEECH | LEAVE | | | |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEEDER | JOIN | START | TRACKING | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEEDER | JOIN | TRACKING | TERMINATE | Invalid |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEEDER | LEAVE | TRACKING | TERMINATE | Valid |
+-----------+-----------+---------+----------+-----------+----------+
Table 6: Validity of Action Combinations in CONNECT RequestsIn the CONNECT request message, multiple swarm action elements ppsp_tp_swarm_action_t can be included. Each one contains the request action and the peer_mode of the peer. The peer_mode attribute MUST be set to the peer's type of participation in the swarm (SEEDER or LEECH) 🐝
The CONNECT message may contain multiple peer_addr elements, with the attributes ip_address, port, priority, and type (if Interactive Connectivity Establishment (ICE) [RFC5245] NAT traversal techniques are used). It can optionally include connection, asn, and peer_protocol for each of the network interfaces the peer wants to advertise 🌐
The peer_num element indicates the maximum number of peers to be returned in a list from the tracker. The returned peer list can optionally be filtered by some indicated properties, such as ability_nat for NAT traversal, and concurrent_links, online_time, and upload_bandwidth for the preferred capabilities 🎯
The transaction_id MUST be present in requests to uniquely identify the transaction. Responses to completed transactions use the same transaction_id as the request they correspond to 🔁
The response may include peer_addr data for the requesting peer's public IP address. Peers can use Session Traversal Utilities for NAT (STUN) [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] to gather their candidates, in which case peer_addr SHOULD NOT be present in the response. If no STUN is used and the tracker is able to work as a "STUN-like" server that can inspect the public address of a peer, the tracker can return the address with a REFLEXIVE attribute type 🪞 The swarm_result may also include peer_addr data corresponding to the peer IDs and public IP addresses of the selected active peers in the requested swarm. The tracker may also include the attribute asn with network location information for the transport address, corresponding to the Autonomous System Number of the access network provider of the referenced peer 🗺️
If the peer_mode is SEEDER, the tracker responds with a SUCCESSFUL response and enters the peer information into the corresponding swarm activity 🌟 If the peer_mode is LEECH (or if a SEEDER includes a peer_num element in the request), the tracker searches and selects an appropriate list of peers that satisfy the conditions set by the requesting peer. The returned peer list MUST contain the peer IDs and the corresponding IP addresses. To create the peer list, the tracker may take peer status and network location information into consideration, to express network topology preferences or operator policy preferences about connecting with other IETF efforts such as Application-Layer Traffic Optimization (ALTO) [RFC7285] 🧠
IMPLEMENTATION NOTE: If no peer_num attributes are present in the request, the tracker may return a random sample from the peer population. 🎲
4.1.1.1. Example
okay bestie, here's the first CONNECT example 💖 A peer wants to start (or restart) sharing content it already streamed, so its peer_mode is SEEDER 🌱
POST https://tracker.example.com/video_1 HTTP/1.1
Host: tracker.example.com
Content-Length: 494
Content-Type: application/ppsp-tracker+json
Accept: application/ppsp-tracker+json
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "CONNECT",
"transaction_id": "12345",
"peer_id": "656164657220",
"connect":{
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "192.0.2.2"
},
"port": 80,
"priority": 1,
"type": "HOST",
"connection": "wired",
"asn": "45645"
},
"swarm_action": [{
"swarm_id": "1111",
"action": "JOIN",
"peer_mode": "SEEDER"
},
{
"swarm_id": "2222",
"action": "JOIN",
"peer_mode": "SEEDER"
}]
}
}
}Next up, another CONNECT message body 🎀 This time the peer is a LEECH, which means it doesn't have the content yet 👀 It wants to join a swarm so it can start receiving the stream, and it's optionally sharing info about its network interface addresses.
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "CONNECT",
"transaction_id": "12345.0",
"peer_id": "656164657221",
"connect":{
"peer_num": {
"peer_count": 5,
"ability_nat": "STUN",
"concurrent_links": "5",
"online_time": "200",
"upload_bandwidth": "600"
},
"peer_addr": [{
"ip_address": {
"address_type": "ipv4",
"address": "192.0.2.2"
},
"port": 80,
"priority": 1,
"type": "HOST",
"connection": "wired",
"asn": "3256546"
},
{
"ip_address":{
"address_type": "ipv6",
"address": "2001:db8::2"
},
"port": 80,
"priority": 2,
"type": "HOST",
"connection": "wireless",
"asn": "34563456",
"peer_protocol": "PPSP-PP"
}],
"swarm_action": {
"swarm_id": "1111",
"action": "JOIN",
"peer_mode": "LEECH"
}
}
}
}Now the switch-channel moment 📺 A peer leaves a swarm it already joined and jumps into a new one. Main character energy 👑 This is the classic "I was watching a live channel and now I'm bored" situation.
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "CONNECT",
"transaction_id": "12345",
"peer_id": "656164657221",
"connect":{
"peer_num": {
"peer_count": 5,
"ability_nat": "STUN",
"concurrent_links": "5",
"online_time": "200",
"upload_bandwidth": "600"
},
"swarm_action": [{
"swarm_id": "1111",
"action": "LEAVE",
"peer_mode": "LEECH"
},
{
"swarm_id": "2222",
"action": "JOIN",
"peer_mode": "LEECH"
}]
}
}
}Here's what the tracker sends back for that last request 💌 The peer asked for two swarm actions and no more than 5 other peers. The tracker only had two peers in swarm "2222" to hand over, so that's all it returned.
HTTP/1.1 200 OK
Content-Length: 1342
Content-Type: application/ppsp-tracker+json
{
"PPSPTrackerProtocol": {
"version": 1,
"response_type": 0,
"error_code": 0,
"transaction_id": "12345",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.1"
},
"port": 80,
"priority": 1,
"asn": "64496"
},
"swarm_result": {
"swarm_id": "2222",
"result": 0,
"peer_group": {
"peer_info": [{
"peer_id": "956264622298",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.22"
},
"port": 80,
"priority": 2,
"type": "REFLEXIVE",
"connection": "wired",
"asn": "64496",
"peer_protocol": "PPSP-PP"
}
},
{
"peer_id": "3332001256741",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.201"
},
"port": 80,
"priority": 2,
"type": "REFLEXIVE",
"connection": "wired",
"asn": "64496",
"peer_protocol": "PPSP-PP"
}
}]
}
}
}
}4.1.2. FIND Request ✨
FIND is how peers ask the tracker for a fresh peer list for the swarm whenever they need one 🔍
A FIND request can include a peer_number element, which tells the tracker the maximum number of peers to return in the list 🔢 The list is shaped by the conditions the requesting peer sets: ability_nat for NAT traversal (considering that PPSP-ICE NAT traversal techniques may be used, because NAT is the boss of everything 🙄), and optionally concurrent_links, online_time, and upload_bandwidth for the preferred capabilities.
When the tracker gets a well-formed FIND request, it checks that the information is valid 💅 If that goes well, it generates a response message with a response value of SUCCESSFUL. Then it searches out the list of peers for the swarm and picks an appropriate peer list that satisfies the conditions the requesting peer set. The peer list returned MUST contain the peer IDs and the corresponding IP addresses.
The tracker may take the ability of peers and the popularity of the requested content into account 🦋 For example, it could select peers with higher ability than the current peers that provide the content if the content is relatively popular (see Section 5.1.1). It could also select peers with lower ability than the current content providers when the content is relatively uncommon. The tracker may also consider network location information, to express network topology preferences or operators' policy preferences. It can implement other IETF efforts like ALTO [RFC7285], which is out of the scope of this document.
The response MUST include a peer_group element that contains the peer IDs and the corresponding IP addresses. It may also include the attribute asn with network location information of the transport address, which is the Autonomous System Number of the access network provider of the referenced peer 🌍
The response may also include a peer_addr element that holds the requesting peer's public IP address. If no STUN is used and the tracker can work as a "STUN-like" server that inspects the public address of a peer, the tracker can return that address with a "REFLEXIVE" attribute type 🧚
IMPLEMENTATION NOTE: If no peer_num attributes are present in the request, the tracker may return a random sample from the peer population 🎲
4.1.2.1. Example
okay so this is the FIND request in action 🔍✨ the peer asks the tracker for no more than 5 peers in swarm "1111" that match the vibe it wants (concurrent links, online time, and upload bandwidth) 💅
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "FIND",
"transaction_id": "12345",
"peer_id": "656164657221",
"swarm_id": "1111",
"peer_num": {
"peer_count": 5,
"ability_nat": "STUN",
"concurrent_links": "5",
"online_time": "200",
"upload_bandwidth": "600"
}
}
}and here's the response to that FIND, which includes the public IP info of the requesting peer 🦋 it's giving full address book energy 📇
{
"PPSPTrackerProtocol": {
"version": 1,
"response_type": 0,
"error_code": 0,
"transaction_id": "12345",
"swarm_result": {
"swarm_id": "1111",
"result": 0,
"peer_group": {
"peer_info": [{
"peer_id": "656164657221",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.1"
},
"port": 80,
"priority": 1,
"type": "REFLEXIVE",
"connection": "wireless",
"asn": "64496"
}
},
{
"peer_id": "956264622298",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.22"
},
"port": 80,
"priority": 1,
"type": "REFLEXIVE",
"connection": "wireless",
"asn": "64496"
}
},
{
"peer_id": "3332001256741",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.201"
},
"port": 80,
"priority": 1,
"type": "REFLEXIVE",
"connection": "wireless",
"asn": "64496"
}
}]
}
}
}
}4.1.3. STAT_REPORT Request
okay this one is how peers send their status and stats over to trackers 📊💖 the peer kinda does it on a schedule while it's active, so the tracker always knows what's up 🫶
the peer MUST set the request_type to "STAT_REPORT", set the peer_id to its own identifier, and generate and set the transaction_id 🎀
the report can carry several statistics elements about different things going on in a specific swarm 🌸 those can be stream stats and peer status info, like uploaded_bytes, downloaded_bytes, available_bandwidth, concurrent_links, and so on, literally a whole vibe check ✨
other properties can also be defined (check the guidelines in Section 7.1) like stuff for incentives and reputation mechanisms 👑 and if there's no Statistics Group in the message, the STAT_REPORT is basically acting as a "keep-alive" 💜 it stops the tracker from de-registering the peer when the "track timer" runs out. main character energy for not getting kicked 💅
if the request is valid, the tracker processes the info for later use and sends back a response with a response value of SUCCESSFUL 🦋
the response MUST have the same transaction_id value as the request 🔥 no mismatched IDs, bestie 🙈
4.1.3.1. Example
here's what a STAT_REPORT request body looks like 🧚
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "STAT_REPORT",
"transaction_id": "12345",
"peer_id": "656164657221",
"stat_report": {
"type": "STREAM_STATS",
"Stat": {
"swarm_id": "1111",
"uploaded_bytes": 512,
"downloaded_bytes": 768,
"available_bandwidth": 1024000,
"concurrent_links": 5
}
}
}
}and this is the response for the START_REPORT request 🌈 (yes the original example says START_REPORT here, it's giving a little inconsistency, so keep that in mind 🙈)
{
"PPSPTrackerProtocol": {
"version": 1,
"response_type": 0,
"error_code": 0,
"transaction_id": "12345",
"swarm_result": {
"swarm_id": "1111",
"result": 0
}
}
}4.2. Response Element in Response Messages
okay so Table 7 is the cheat sheet for response types and what they mean 📋✨
+--------------------+---------------------+
| Response Type | Semantics |
| | |
+--------------------+---------------------+
| 0 | SUCCESSFUL |
| 1 | FAILED |
+--------------------+---------------------+
Table 7: Semantics for the Value of Response TypeSUCCESSFUL means the request was processed properly and the desired operation finished 🎉 the response body has the requested info, and it MUST include the same transaction_id as the request 💖
- CONNECT: returns info confirming the peer registered successfully and/or each swarm action that was asked for. it can also return the list of peers that match the action attribute requested 🌸
- FIND: returns the list of peers that match the requested scope 🔍
- STAT_REPORT: confirms the requested operation worked 💅
FAILED means the request was NOT processed properly 💀 a corresponding error_code SHOULD be set based on the conditions in Section 4.3 🫶
4.3. Error and Recovery Conditions
okay this part is so important for not spiraling 😭🎀
if the peer gets an invalid response, it MUST repeat the same request with identical content, including the same transaction_id 🔁
a transaction_id on a request can be reused if and only if ALL of the content is identical, including date/time info 🕰️ (the rule is strict, no cap 💅) how the retry goes (like how long to pause, how many retries to try, and timeouts) is totally implementation dependent, so each implementation picks its own vibe 🧚
the tracker MUST be prepared to receive a request with a repeated transaction_id 🫶 it's giving "I've seen this before and I'm not spooked" 👑
error situations, whether from normal operation or from abnormal conditions (Section 2.3.2), MUST be answered with response_type set to 0x01 and the adequate error_code, as described here 🚨
- If the message is found to be incorrectly formed, the receiver MUST respond with a 01 (Bad Request) error_code with an empty message-body (no peer_addr and swarm_result attributes) 🙈
- If the version number of the protocol is for a version the receiver does not support, the receiver MUST respond with a 02 (Unsupported Version Number) error_code with an empty message-body (no peer_addr and swarm_result attributes) 💀
- In the PEER REGISTERED and TRACKING states of the tracker, certain requests are not allowed (Section 2.3.2). The tracker MUST respond with a 03 (Forbidden Action) error_code with an empty message-body (no peer_addr and swarm_result attributes) 🚫
- If the tracker is unable to process a request message due to an unexpected condition, it SHOULD respond with a 04 (Internal Server Error) error_code with an empty message-body (no peer_addr and swarm_result attributes) 🔥
- If the tracker is unable to process a request message because it is in an overloaded state, it SHOULD respond with a 05 (Service Unavailable) error_code with an empty message-body (no peer_addr and swarm_result attributes) 😭
- If authentication is required for the peer to make the request, the tracker SHOULD respond with a 06 (Authentication Required) error_code with an empty message-body (no peer_addr and swarm_result attributes) 🔐
4.4. Parsing of Unknown Fields in message-body
this doc only details the object members this spec actually uses 🧩 extensions may add extra members inside the JSON objects defined here, and that's totally fine 🌈 PPSTP implementations MUST ignore unknown members when processing PPSTP messages 🫶 no drama, just skip 'em 💅
5. Operations and Manageability ✨
this section covers the operational and management stuff you need to think about when implementing PPSTP 🛠️ it follows the recommendations in [RFC5706] 📚
5.1. Operational Considerations
okay so PPSTP is about communication between trackers and peers, and it's built as a "client-server" mechanism 🎀 it lets participant peers swap info about each other while they share multimedia streaming content 🎬
the "server" side, aka the tracker, is a logical entity 🧠 it can be imagined as a centralized service (running on one or more physical nodes) or as a fully distributed service 🌐
the "client" side can be implemented at each peer taking part in streaming the content 🦋
5.1.1. Installation and Initial Setup
okay so content providers who wanna use PPSP for distribution should set up at least a PPSP tracker and a service portal (public web server) 🌸. the portal is where they publish links to the content descriptions, so people can reach their on-demand or live original content sources. they should also make conditions for generating peer IDs and any required security certificates, plus chunk IDs and swarm IDs for each streaming content 🎀. the setup processes for the PPSP tracking facility, the service portal, and the content sources are not standardized, so implementers get lots of flexibility 💅✨
the swarm IDs of available content and the addresses of the PPSP tracking facility can reach end users in different ways 🦋. but it's common practice to put both the swarm ID and the matching PPSP tracker addresses (as URLs) in the MPD of the content, which you can grab as a link from the service portal 💜
the available content could have different importance attribute values to show whether it's popular or not 🔥. however, that's a totally implementation design thing and outside the scope of this specification 🙈. for example, content providers could set the importance attribute values when they distribute the content, or the tracker could work them out from the statistics of the requests coming from peers 📊. the tracker could set an upper threshold to decide the content is popular enough when its importance attribute value is higher than that upper threshold 👑. it could also set a lower threshold to decide the content is uncommon enough when its importance attribute value is lower than that lower threshold 🧚
end users browse and search for the content they want in the service portal, then select it by clicking the links to the matching MPDs 💖. this usually needs security certificates or authorization tokens from an enrollment service (end-user registration) 🫶. then it launches the Client Media Player (with PPSP awareness), which uses PPSTP to contact the PPSP tracker, join the right swarm, and grab the transport addresses of other PPSP peers so it can start streaming 🍓✨
5.1.2. Migration Path
okay this one's kinda sad but also real 😭. there's no previous standard protocol that does something similar to PPSTP 🥺. however, some popular proprietary protocols, like BitTorrent, are used in existing systems 🌈. there's no way for PPSTP to migrate to proprietary protocols like the BitTorrent tracker protocol 🙅♀️. and since PPSTP is an application-level protocol, there's no harm in PPSTP having no migration path 🤷♀️. still, proprietary protocols moving over to standard protocols like PPSTP can solve the problems raised in [RFC6972] 💅. it's also possible for systems to use PPSTP as the management protocol to work with existing proprietary peer protocols, like the BitTorrent peer protocol 🎀
5.1.3. Requirements on Other Protocols and Functional Components
for security reasons, when you're using the Peer-to-Peer Streaming Peer Protocol (PPSPP) with PPSTP, you should observe the mechanisms described in Section 6.1 🔐🫶
5.1.4. Impact on Network Operation
the messaging model of PPSTP lines up with HTTP and the semantics of its messages 🦋. so the impact on network operation is pretty much the same as using HTTP, no surprises ✨
5.1.5. Verifying Correct Operation
you can check that PPSTP is running correctly at both the tracker and the peer by logging its behavior 📝💖. also, the PPSP tracker collects the status of peers, including their activity 👀. that info can be used to monitor things and get the global view of the operation 🌍💅
5.2. Management Considerations
the management considerations for PPSTP are similar to other solutions that use HTTP for large-scale content distribution 🍓. the PPSP tracker can be made of geographically distributed tracker nodes or multiple server nodes in a data center 🏢. since these nodes are basically like WWW nodes, their configuration procedures, fault detection, performance measurement, usage accounting, and security measures can all be handled by standard solutions and facilities 🛠️💜
5.2.1. Interoperability
interoperability is about letting information get shared and operations happen between multiple devices and multiple management applications 🤝. for PPSTP, different kinds of devices host PPSTP trackers and peers 📱💻. so the PPSTP design considered support for multiple standard schema languages, management protocols, and information models, each suited to different purposes 🌸. specifically, management of PPSTP devices can be done 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 needing to instrument the tracker application itself 🧚. the channel, connections, and transaction objects of the Application Management MIB can 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 give you solid metrics for analyzing performance of transaction flows in the network, directly tied to the transport of PPSTP 🔥💅
the Host Resources MIB [RFC2790] can supply info on the hardware, the operating system, and the installed and running software on a PPSP tracker host 🖥️🫶
the TCP-MIB [RFC4022] can also be considered for network monitoring 👀🦋
logging is a big deal for PPSTP trackers and peers 📝👑, and it's done via syslog [RFC5424] 💖
5.2.3. Fault Management
okay so PPSP tracker failures can mostly be traced to the host or the network conditions 🏠🌐. because of that, the facilities we already described for checking that PPSTP runs correctly, plus managing the PPSP tracker servers, seem sufficient for PPSTP fault monitoring 💅✨
5.2.4. Configuration Management
when PPSP tracker deployments are made of geographically distributed tracker nodes or multiple server nodes in a data center, they may benefit from a standard way of replicating atomic configuration updates across a set of server nodes 🌍. this can be provided via NETCONF [RFC6241] 🎀
5.2.5. Accounting Management
PPSTP implementations, mainly in content provider environments, can benefit from the accounting standardization efforts described in [RFC2975] 💰. that document says 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
PPSTP is transaction oriented, so you can measure its performance in terms of availability and responsiveness using the APM-MIB [RFC3729] and the TPM-MIB [RFC4150] facilities ⏱️🔥
5.2.7. Security Management
standard SNMP notifications for PPSP tracker management [RFC5590] and syslog messages [RFC5424] can alert operators to the conditions identified in the security considerations (Section 6) 🚨🛡️
the statistics collected about PPSTP operation can help detect attacks, like receiving malformed messages, messages out of order, or messages with invalid timestamps 🕵️♀️. but collecting these endpoint properties can also raise security issues 😬. for example, the statistics the tracker collects might get disclosed to an unauthorized third party with malicious intentions 💀. to deal with that risk, the tracker's provider should evaluate how much information gets revealed and what the associated risks are 🔍. a confidentiality mechanism must be provided by HTTP over TLS to guarantee the confidentiality of PPSTP 🔐🫶
6. Security Considerations 🛡️
okay this section is seriously important, bestie, so read it closely 🙈💀. P2P streaming systems are open to attacks from malicious or unfriendly peers and trackers 😈. these can eavesdrop on signaling, forge or deny information and knowledge about streaming content 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 here is to give enough protection to keep some security properties during tracker-peer communication, even when there are lots of malicious peers and/or trackers that eventually can't be trusted (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 🌸. because the communication between peers and tracker is transactional, the method for adding authentication and data security services can be OAuth 2.0 Authorization [RFC6749] with a bearer token 🎟️. that gives the peer the info it needs to successfully use 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, 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 info about the authentication mechanisms 🪪. the specification of the enrollment method and the provision of identifiers and authentication tokens is out of scope for this specification 🙅♀️
Transport Layer Security (TLS) [RFC5246] MUST be used in the communication between peers and tracker to provide privacy and data integrity. this one's non-negotiable, periodt 🔒💅
software engineers developing and service providers deploying the tracker should get 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 ✨
okay so bestie, malicious peers can totally claim they own popular content to the tracker and then serve polluted stuff to everyone else 😭 we're talking decoy content or even virus/trojan-infected files. 💀 And since trackers don't swap content info between peers, it's hard to tell when a peer is polluting things. 🙈 Usually this kind of pollution can be detected by the Peer-to-Peer Streaming Peer Protocol (PPSPP) [RFC7574], with the use of the Merkle Hash Tree scheme required to protect content integrity. 🌸 You can check out Section 5 of [RFC7574] for the full tea. 🍵
Some attackers who want to mess with P2P streaming on behalf of content providers might serve false or modified content, or fake peer list info, to get what they want. 😈 Peers who connect to those portals or trackers can get redirected to corrupted content, and honestly there's no standard way for peers to avoid that completely. 😤 Peers can have their own mechanisms to spot undesirable content or results, though. 🦋 For example, if a peer notices that a portal sent back undesired content info, or that a tracker returned sketchy peer lists, the peer may choose to quit the swarm or switch over to other P2P streaming services run by other content providers. 🏃♀️💨
6.3. Residual Attacks and Mitigation 💅
To soften the blow of Sybil attackers who impersonate a huge number of valid participants by grabbing lots of different peer identities, the enrollment server SHOULD carefully regulate the rate of peer/tracker admission. 🚦 Not letting the floodgates just swing open is the vibe. 🫶
Here's the thing though: there's no guarantee that peers honestly report their status to the tracker, or that they serve authentic content to other peers the way they told the tracker they would. 💀 It's expected that a global trust mechanism could help with this, where each peer's credit builds up from evaluations of its past transactions. 🌈 Other peers might take that credit into account when picking partners for future transactions, which helps cut down on the damage from all that shady behavior. 💜 A globally trusted tracker could also join the trust mechanism by collecting evaluations, computing credit values, and handing them out to joining peers. 👑
6.4. Pro-incentive Parameter Trustfulness 🎀
Property types for STAT_REPORT messages can include extra pro-incentive parameters (see the guidelines for extension in Section 7), which lets the tracker level up the performance of the whole P2P streaming system. 📈 But these parameters are only useful if they can be trusted, because the incentive mechanisms depend on them. 🔥 On top of that, the amount of both uploaded and downloaded data should be reported to the tracker, so it can check for inconsistencies between the upload and download reports and set up a proper credit/trust system. 🧾
One option is a reputation-incentive mechanism built on reputation, social awareness, and fairness. 🤝 It would encourage cooperation among participants, with each peer's reputation shaped by its history of past transactions. ⭐ That history could include things like the count of chunk requests (sent and received) in a swarm, the peer's contribution time, cumulative uploaded and downloaded content, JOIN and LEAVE timestamps, attainable rate, and so on. 📊
Another route is exchanging cryptographic receipts signed by the receiving peers, which can be used to attest to a peer's upload contribution to the swarm, as suggested in [Contracts]. 🧾✍️
6.5 Privacy for Peers 🙈🔐
PPSTP has mechanisms where peers can send messages containing IP addresses, ports, and other info to the tracker. 📬 Now, a tracker, or any third party that can intercept those messages, can store and process that info to analyze peers' behaviors and communication patterns. 👀 That kind of analysis can lead to privacy risks, bestie. 😬 For example, an unauthorized party could snoop on the data going from a peer to a tracker and use that to slip in some corrupted chunks. 💀
PPSPP [RFC7574] already brought in some ways to protect streamed content, so check out Sections 12.3 and 12.4 of [RFC7574] for those. 🛡️ For PPSTP, peer implementations as well as tracker implementations MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. 🔒✨ Also, a peer should be cognizant about potential trackers tracking it through queries, for example by using HTTP cookies. 🍪👀 PPSTP as specified in this document doesn't rely on HTTP cookies at all, so peers may decide not to return cookies received from the tracker, which makes extra tracking way harder. 🙅♀️🍪❌
7. Guidelines for Extending PPSTP 🧚
Extension mechanisms let designers add new features or customize existing ones for different operating environments [RFC6709]. 🌸
Extending a protocol means either adding features without changing the protocol itself, or adding new elements that create new versions of an existing schema, and therefore new versions of the protocol. 🦋
In PPSTP, that means an extension MUST NOT alter an existing protocol schema. Changing it would produce a new version of an existing schema rather than an extension of it, and that's typically non-backwards-compatible. 🚫💔
Also, a designer MUST remember that extensions themselves may also be extensible. 🪆 And for an extension to be considered valid, it MUST adhere to the principles described in this section. ✅ If there are requirements for coordination, interoperability, and broad distribution, extensions MUST be documented in Standards Track RFCs. 📜👑
7.1. Forms of PPSTP Extension 💖
In PPSTP there are two extension mechanisms you can use: 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 could be considered, with new messages (JOIN, DISCONNECT), a retro-compatible change in semantics of an existing CONNECT request/response, and an extension in STAT_REPORT. 🧠✨
As illustrated in Figure 6, the peer would use an enhanced CONNECT request to do 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 ✨
okay so this section is where the IANA gets to officially register our media type, and honestly it's giving main character energy 💖 🎀
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/jsonmedia 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
- Magic number(s):
- 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 made a whole PPSTP Version Number Registry for us, and we're obsessed 😭 Values are integers from 0-255. The initial assignments and reservations are in Table 2. New PPSTP version types get assigned after IETF Review [RFC5226], so somebody has to actually check that the documentation for each new version and how it's used is legit. Responsible behaviour, iconic 👑
8.3. PPSTP Request Type Registry 🌸
Same energy here: IANA created the PPSTP Request Type Registry 🍓 The values are strings listed in Table 8. New PPSTP request types also need IETF Review [RFC5226] before they get in, which means they need proper documentation about what they are and how to use them. No mystery requests allowed, periodt 💅
+----------------------+-------------------------------------------+
| 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 💀
And last but not least, IANA made the PPSTP Error Code Registry 🙈 The values are the strings in Table 9. New PPSTP error codes also go through IETF Review [RFC5226], so the usage gets properly documented before anyone can add one. The error codes are the bestie list of "what went wrong" 😭
+---------------+-------------------------------------------+
| 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 🫶
These are the docs we absolutely need to read before we can understand this spec, so bookmark them 🔖
- [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 📚
okay bestie, here are the receipts 🧾 these are the background reads that helped shape everything, and they're not the must-read stuff, just the cute extra context 💅
[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 🫶
huge thanks to Yingjie Gu for helping out in the early stages of the spec 💖 and a big group hug to everyone else who gave 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 opinions in here are the authors' own 🎀 and they're not necessarily the official policies or endorsements, spoken or unspoken, 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.comthat's the whole thing, bestie! 🌈👑 PPSTP is officially explained, and you absolutely slayed the read 🦋💅
📦 where this page comes from
- ietf: rfc7846 2016-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms