Peer-to-Peer Streaming Tracker Protocol (PPSTP)
Extracted elements (32)
PPSTP uses a REST-like design over HTTP to leverage existing HTTP implementations and infrastructure, with messages encoded in JSON (RFC 7159) and using the HTTP POST method to send request parameters. This aligns with the HTTP messaging model (currently version 1.1) and is intended to also support future HTTP versions.
The CONNECT request may contain peer_addr elements with ICE (RFC 5245) candidate information. If STUN (RFC 5389) or TURN (RFC 5766) is used to gather candidates, peer_addr SHOULD NOT be present in the response. If no STUN is used and the tracker can inspect the peer's public address, it can return it with type 'REFLEXIVE'.
The tracker may integrate with ALTO (RFC 7285) when building peer lists, using network topology and operator policy preferences, though this is outside the scope of PPSTP. Management of PPSTP trackers can leverage SNMP, syslog (RFC 5424), and NETCONF (RFC 6241).
Error situations MUST be responded to with response_type set to 0x01 and the appropriate error_code: 01 (Bad Request) for malformed messages, 02 (Unsupported Version Number) for unknown versions, 03 (Forbidden Action) for disallowed state transitions, 04 (Internal Server Error) for unexpected conditions (SHOULD), 05 (Service Unavailable) for overload (SHOULD), and 06 (Authentication Required) when authentication is needed (SHOULD).
If a peer receives an invalid response, the same request with identical content including the same transaction_id MUST be repeated. The transaction_id may be reused only if all content including date/time information is identical.
Implementations MUST support the 'https' URI scheme (RFC 2818) and Transport Layer Security (TLS) (RFC 5246). For scenarios where peer client authentication is desired, HTTP Digest Access Authentication (RFC 7616) MUST be supported, with TLS Client Authentication as the preferred mechanism if available.
PPSTP implementations MUST ignore unknown members when processing PPSTP messages, to allow forward-compatible extensions that add additional JSON object members.
The Content-Type field in HTTP/1.1 MUST indicate the 'application/ppsp-tracker+json' media type for all PPSTP request parameters and responses.
The peer ID MUST be unique. It can take the form of a UUID (RFC 4122) and can be bound to a network address. The peer ID and any required security certificates are obtained from an offline enrollment server.
The peer list returned in response to CONNECT (LEECH mode) and FIND requests MUST contain the peer IDs and the corresponding IP addresses.
The peer_mode attribute in CONNECT requests MUST be set to the type of participation of the peer in the swarm (SEEDER or LEECH).
The request element MUST be present in requests. The request_data field MUST be correctly set to the element corresponding to the request_type (connect for CONNECT, find for FIND, stat_report for STAT_REPORT).
The STAT_REPORT request message MUST be sent periodically to the tracker while the peer is active in the system to signal continuing activity and prevent the tracker from de-registering the peer when the 'track timer' expires.
The transaction_id element MUST be present in requests to uniquely identify the transaction. Responses to completed transactions MUST use the same transaction_id as the corresponding request.
The version of PPSTP being used MUST be indicated by the 'version' attribute in both requests and responses. The only defined value is 1 (PPSTP version 1); value 0 is reserved.
The tracker maintains peer IP addresses and swarm membership, creating privacy exposure. Peers' participation in content swarms is visible to the tracker. The spec notes that the pro-incentive parameters (upload statistics) reported via STAT_REPORT must be trustworthy to prevent free-riding but acknowledges the privacy trade-off of reporting such data.
PPSTP defines three request message types: CONNECT (peer registration and swarm join/leave), FIND (request updated peer list from tracker), and STAT_REPORT (periodic status/statistics reporting). All are sent via HTTP POST from peers to trackers.
The peer address element (ppsp_tp_peer_addr_t) includes ip_address (address_type + address), port, priority, type ('HOST'|'REFLEXIVE'|'PROXY'), and optional connection ('wireless'|'wired'), asn, and peer_protocol fields. IPv4 addresses follow RFC 3986 Section 3.2.2; IPv6 addresses follow RFC 5952 Section 4.
The peer number element (ppsp_tp_peer_num_t) is an optional scope selector in CONNECT and FIND requests specifying peer_count (maximum peers to return, should be less than 30) and optional filter attributes: ability_nat ('NO_NAT'|'STUN'|'TURN'), concurrent_links, online_time (seconds), and upload_bandwidth (Kbps).
The statistics element for type 'STREAM_STATS' includes swarm_id, uploaded_bytes, downloaded_bytes, available_bandwidth, and concurrent_links. Multiple stat blocks can be reported in a single STAT_REPORT message. If no Statistics Group is included, STAT_REPORT serves as a keep-alive message.
The swarm action element (ppsp_tp_swarm_action_t) identifies the action to take in a named swarm: swarm_id (string), action ('JOIN'|'LEAVE'), and peer_mode ('SEEDER'|'LEECH'). Multiple swarm action elements may be included in a single CONNECT request.
IANA created the PPSTP Error Code Registry with initial values: 00 (No Error), 01 (Bad Request), 02 (Unsupported Version Number), 03 (Forbidden Action), 04 (Internal Server Error), 05 (Service Unavailable), and 06 (Authentication Required). New error codes require Standards Action.
IANA created the PPSTP Request Type Registry with initial values: CONNECT, FIND, and STAT_REPORT. New request types require Standards Action.
IANA created the PPSTP Version Number Registry. Value 0 is Reserved, value 1 is 'PPSTP version 1', and values 2–255 are Unassigned. New values require Standards Action.
IANA registered MIME type 'application/ppsp-tracker+json' (type: application, subtype: ppsp-tracker+json) for PPSTP messages, with required parameter 'version' indicating the PPSTP version.
Authentication between tracker and peers is required to prevent unauthorized peers from joining swarms or obtaining peer lists. The recommended mechanism is TLS Client Authentication; HTTP Digest Access Authentication (RFC 7616) MUST also be supported. The tracker validates peer authentication information on every CONNECT request.
Content integrity protection against polluting peers and trackers is a concern: a malicious tracker could return a list of polluter peers, or polluter peers could inject corrupted chunks. Implementers should use content integrity mechanisms at the peer layer (e.g., as defined in PPSPP/RFC 7574) to mitigate this.
Residual attacks include Sybil attacks (a single entity controlling many peer IDs to gain disproportionate influence), eclipse attacks (isolating a peer by controlling all entries in its peer list), and tracker impersonation. Mitigation relies on secure authentication and enrollment. Tracker responses to abnormal conditions proceed to TERMINATE state for that peer ID.
A per-Peer-ID state machine is instantiated for each registered peer with states: START (transient, on registration), PEER REGISTERED (after CONNECT received), TRACKING (after successful swarm action processing), and TERMINATE (transient, on deregistration or error). Timeout of the 'track timer' in TRACKING state causes cleanup and transition to TERMINATE. The machine is destroyed on entering TERMINATE.
The tracker-level state machine has three states: INIT (no peers connected), STARTED (at least one peer ID registered), and TERMINATED (last peer ID removed, transient—immediately returns to INIT). The machine transitions from INIT to STARTED when the first peer registers, and from STARTED to TERMINATED (then immediately INIT) when the last registration is removed.
A PPSTP request is a JSON object with root key 'PPSPTrackerProtocol' containing fields: version (integer), request_type (string: 'CONNECT'|'FIND'|'STAT_REPORT'), transaction_id (string), peer_id (string), and request_data (one of connect, find, or stat_report objects). All messages are sent via HTTP POST with Content-Type application/ppsp-tracker+json.
A PPSTP response is a JSON object with root key 'PPSPTrackerProtocol' containing fields: version (integer), response_type (0x00=SUCCESSFUL|0x01=FAILED), error_code (integer), transaction_id (string), optional peer_addr, and optional swarm_result array. swarm_result elements contain swarm_id, result, and optional peer_group with peer_info entries.