PPSP Rui S. Cruz INTERNET-DRAFT IST/INESC-ID/INOV Intended Status: Informational Mario S. Nunes Expires: December 2, 2011 IST/INESC-ID/INOV Joao P. Taveira IST/INOV May 31, 2011 HTTP-based PPSP Peer Protocol draft-cruz-ppsp-http-peer-protocol-00 Abstract This document presents a proposal for an HTTP-based P2P streaming Peer Protocol, outlining the requirements, functional entities, message flows, formal syntax and semantics, with detailed message processing instructions using an HTTP/XML encoding, the respective parameters, methods, and message formats. The PPSP Peer Protocol proposed in this document extends the capabilities of PPSP to support adaptive and scalable video, for Video On Demand (VoD) and Live video services. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Cruz, et al. Expires December 2, 2011 [Page 1] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Streaming Modes . . . . . . . . . . . . . . . . . . . . . . 10 3.4 Chunk Scheduling . . . . . . . . . . . . . . . . . . . . . 11 3.5 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . 11 3.6 Manifest File . . . . . . . . . . . . . . . . . . . . . . . 11 4 Messages syntax and processing . . . . . . . . . . . . . . . . 14 4.1 HTTP/XML Encoding . . . . . . . . . . . . . . . . . . . . . 14 4.2 Method Fields . . . . . . . . . . . . . . . . . . . . . . . 15 4.3 Message Processing . . . . . . . . . . . . . . . . . . . . 16 4.4 GET_PEERLIST Message . . . . . . . . . . . . . . . . . . . 16 4.5 GET_CHUNKMAP Message . . . . . . . . . . . . . . . . . . . 19 4.6 GET_CHUNK Message . . . . . . . . . . . . . . . . . . . . . 20 4.7 PEER_STATUS Message . . . . . . . . . . . . . . . . . . . . 22 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 23 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 23 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1 Normative References . . . . . . . . . . . . . . . . . . . 23 8.2 Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Cruz, et al. Expires December 2, 2011 [Page 2] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 1 Introduction The P2P Streaming Protocol (PPSP) is composed of two protocols: the PPSP Tracker Protocol and the PPSP Peer Protocol [I-D.ietf-ppsp-problem-statement]. The PPSP Tracker Protocol provides communication between Trackers and Peers, by which Peers exchange meta information with trackers, report streaming status and request candidate lists from trackers. The PPSP Peer protocol controls the advertising and exchange of media data directly between peers. The PPSP architecture requires PPSP peers able to communicate with a tracker in order to participate in a particular swarm. This centralized tracker service is used for peer boostraping and for for content registration and location. Content indexes (manifest files) are also stored in the tracker system allowing the association of content location information to the active peers sharing the content in the swarm. The signaling between PPSP Peers and trackers is done using a request/reply mechanism as defined in PPSP Tracker protocol [I-D.gu-ppsp-tracker-protocol]. The signaling between PPSP Peers can also be done using a request/reply mechanism proposed in this document as PPSP Peer protocol. The process used for streaming distribution relies on a chunk transfer scheme whereby the original content is re-encoded using adaptive or scalable techniques and then chopped into small video chunks with a short duration: 1. (adaptive) - alternate versions with different qualities and bitrates; 2. (scalable description levels) - multiple additive descriptions (i.e., addition of descriptions refine the quality of the video); 3. (scalable layered levels) - nested dependent layers corresponding to several hierarchical levels of quality, i.e., higher enhancement layers refine the quality of the video of lower layers. These streaming distribution techniques support dynamic variations in video streaming quality while ensuring support for a plethora of end user devices and network connections. Cruz, et al. Expires December 2, 2011 [Page 3] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 The information that should be exchanged among peers using this peer protocol includes: 1. peer lists, for the swarms they are participating in. 2. chunk maps, indicating which chunks a peer possesses (for both VoD and Live streaming). 3. required chunks. 4. peer activity and status. 5. information to help improve the performance of PPSP. This PPSP Peer Protocol proposal presents an early sketch for an extensible protocol that extends the capabilities of PPSP to support adaptive and scalable video, as a way to identify open issues and further discussion in the PPSP WG [I-D.ietf-ppsp-survey]. 2 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 RFC 2119 [RFC2119]. This draft uses the terms defined in [I-D.ietf-ppsp-problem-statement] and in [I-D.gu-ppsp-tracker-protocol]. Absolute Time: Absolute time is expressed as ISO 8601 [ISO.8601.2004] timestamps, using zero UTC offset (GMT). Fractions of a second may be indicated. Example for December 25, 2010 at 14h56 and 20.25 seconds: basic format 20101225T145620.25Z or extended format 2010-12-25T14:56:20.25Z. Adaptive Streaming: multiple alternate versions (different qualities and bitrates) of the same media content co-exist for the same streaming session; each alternate version corresponds to a different media quality level; peers can choose among the alternate versions for decode and playback. Base Layer: the playable level in Scalable Video Coding (SVC) required by all upper level Enhancements Layers for proper decoding of the video. Chunk: A chunk is a basic unit of partitioned streaming media, which is used by a peer for the purpose of storage, advertisement and exchange among peers. Cruz, et al. Expires December 2, 2011 [Page 4] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 Enhancement Layer: enhancement differential quality level in Scalable Video Coding (SVC) used to produce a higher quality, higher definition video in terms of space (i.e., image resolution), time (i.e., frame rate) or Signal-to-Noise Ratio (SNR) when combined with the playable Base Layer. Live streaming: The scenario where all clients receive streaming content for the same ongoing event. The lags between the play points of the clients and that of the streaming source are small. Manifest: The manifest file holds information about the content, i.e., describes the structure of the media, namely, the codecs used, the chunks, and the corresponding mapping within a container file system. Peer: A peer refers to a participant in a P2P streaming system that not only receives streaming content, but also stores and uploads streaming content to other participants. PeerID: Unique identifier for the peer. The PeerID and any required security certificates are obtained from an offline enrollment server. Peer-Peer Messages (i.e., Peer Protocol): The Peer Protocol messages enable each Peer to exchange content availability with other Peers and request other Peers for content. PPSP: The abbreviation of P2P Streaming Protocols. PPSP protocols refer to the key signaling protocols among various P2P streaming system components, including the tracker and peers. Scalable Streaming: With Multiple Description Coding (MDC), multiple additive descriptions (that can be independently played-out) to refine the quality of the video when combined together. With Scalable Video Coding (SVC), nested dependent enhancement layers (hierarchical levels of quality), refine the quality of lower layers, from the lowest level (the playable Base Layer). Swarm: A swarm refers to a group of clients (i.e., peers) sharing the same content (e.g., video/audio program, digital file, etc.) at a given time. SwarmID: Unique identifier for certain swarm. It is used to describe a specific resource shared among peers. Tracker: A tracker refers to a directory service which maintains the lists of PPSP peers storing chunks for a specific channel or streaming file, and answers queries from PPSP peers. Cruz, et al. Expires December 2, 2011 [Page 5] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 Tracker-Peer Messages (i.e., Tracker Protocol): The Tracker Protocol messages provide communication between Peers and Trackers, by which Peers provide content availability, report streaming status and request candidate Peer lists from Trackers. Video-on-demand (VoD): A kind of application that allows users to select and watch video content on demand. 3. Protocol Overview The function entities involved in the PPSP Peer Protocol are Peers which may support different capabilities. Peers are of two types (in terms of media sharing role): Seeder and Leecher. The Seeder holds the complete media content (i.e., the container with all the corresponding chunk files). The Leecher is a Peer that is downloading the content and has not yet completed the transfer of all chunk files of the media content (although contributes to the swarm with the files already downloaded). Peers are organized in (various) swarms corresponding each swarm to the group of peers sharing a content at any given time. A P2P streaming process is summarized in Figure 1. When a peer wants to receive streaming of a selected content: 1. Peer connects to a tracker and joins a swarm. 2. Peer acquires a list of peers from the tracker. 3. Peer exchanges its content availability with the peers on the obtained peer list. 4. Peer identifies the peers with desired content. 5. Peer requests for the content from the identified peers. When a peer wants to share streaming of certain content with others: 1. Peer connects to the tracker. 2. Peer sends information to the tracker about the swarm it belongs to (joins), plus streaming status and/or content availability. Cruz, et al. Expires December 2, 2011 [Page 6] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 +-----------------------------------+ | Tracker | +-----------------------------------+ ^ | ^ connect/ | | | join/ | | peer list |streaming Status/ query | | |Content availability/ | | |node capability | V | +-------------+ +------------+ | Peer 1 |<------------->| Peer 2 | +-------------+ content info/ +------------+ data requests Figure 1: A PPSP streaming process The PPSP Peer Protocol messages allow for information to be shared directly between Peers. This information includes at least the following: 1. peer lists, for the swarms the peers are participating in. 2. chunk maps, indicating which chunks a peer possesses (for both VoD and Live streaming). 3. required chunks. 4. peer activity and status. 5. information to help improve the performance of PPSP. The PPSP Peer Protocol is a request-response protocol. Requests are sent, and responses returned to these requests. A single request generates a single response (neglecting fragmentation of messages). The specific operations of the protocol at present, are (names correspond to Method strings): 1. GET_PEERLIST 2. GET_CHUNKMAP 3. GET_CHUNK 4. PEER_STATUS GET_PEERLIST: This method allows a peer to request the Peer list for a specific content of a particular swarm to other Peers. The method is mainly used for a peer to refresh/update the list of active peers in the swarm. GET_CHUNKMAP: This method allows a peer to request which chunks of a content the other peer presently stores. The chunk map returned by the other peers lists ranges of chunks. Cruz, et al. Expires December 2, 2011 [Page 7] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 GET_CHUNK: This method allows peers to request chunks to the other Peers. PEER_STATUS: This method allows a peer to exchange information with other peer on its participation status. The Response messages correspond to a number of logical responses common to the Tracker or the Peer protocols request messages.Incorrectly formatted XML request bodies are handled by the HTTP protocol itself and reported in an HTTP message. At present, the minimum set of response messages for the PPSP Streaming Protocols is the following: SUCCESSFUL (200 OK): a message has been processed properly and the desired operation has completed. If the message is a request for information, the body of the message will also include the requested information. INVALID SYNTAX (400 Bad Request): Indicates an error in the format of the message/message body. These responses correspond to errors within the XML/PPSP protocol messages, not HTTP. VERSION NOT SUPPORTED (400 Bad Request): Invalid version of the protocol or message bodies. These responses correspond to errors within the XML/PPSP protocol messages, not HTTP. AUTHENTICATION REQUIRED (401 UNAUTHORISED): Authentication is required to access this information. MESSAGE FORBIDDEN (403 FORBIDDEN): The requester is not allowed to make this request. OBJECT NOT FOUND (404 NOT FOUND): The requested object or a swarm that is being searched for cannot be found. INTERNAL ERROR (500 INTERNAL SERVER ERROR): The server was unable to process the request due to an internal error. TEMPORARILY OVERLOADED (503 SERVICE UNAVAILABLE): The server is unable to process this message at this time. 3.1 Assumptions The function entities related to PPSP protocols are the Client Media Player, the service Portal, the Tracker and Peers. Their complete description is not discussed in this document (as not in the scope of this specification). Cruz, et al. Expires December 2, 2011 [Page 8] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 The Client Media Player is the entity providing a direct interface to the end user at the client device, and includes the functions to select, request, decode and render contents. In PPSP the Client Media Player interfaces with the peer using request and response standard formats for HTTP Request and Response messages [RFC2616]. The service Portal is a logical entity typically used for client enrollment and content information publishing, searching and retrieval. The Tracker is a logical entity that maintains the lists of PPSP active peers storing and exchanging chunks for a specific content. The tracker also stores the status of peers, to help in the selection of appropriate candidate peers for a requesting peer. The Peer is also a logical entity embedding the P2P core engine, with a client serving side interface (a proxy HTTP server) to respond to Client Media Player requests and a network side interface (also an HTTP server) to exchange data and PPSP signaling with peers and trackers. 3.2 Bootstrapping In order to join an existing P2P streaming service and to participate in content sharing, any peer must first locate a Tracker service, using for example, the following methods (as illustrated in Figure 2): 1. From a service provider provisioning mechanism: this is a typical case used on the provider Super-Seeders (edge caches and/or Media Servers). 2. From a web page: a Publishing and Searching Portal may provide tracker location information to end users 3. From the Manifest file of a content: this metainfo file must contain information about the address of one or more trackers controlling the swarm for that content. In order to be able to bootstrap, a peer must first obtain a PeerID and any required security certificates from an enrollment service (user registration). Cruz, et al. Expires December 2, 2011 [Page 9] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 +--------+ +--------+ +--------+ +---------+ +--------+ | Player | | Peer 1 | | Portal | | Tracker | | Peer 2 | +--------+ +--------+ +--------+ +---------+ +--------+ | | | | | | Page request | | | | |------------------------------->| | | | Page with links | | | |<-------------------------------| | | | Select stream | | | |------------------------------->| | | | Manifest | | | |<-------------------------------| | | | Manifest | CONNECT | | | |--------------->|----------------------------->| | | |<-------------------------OK--| | | | JOIN | | | |----------------------------->| | | |<-------------------------OK--| | | | GET_PEERS | | | |----------------------------->| | |<-----------OK--|<----------------OK Peerlist--| | | | | | | | GET (Chunk) | GET_CHUNK | | | |--------------->|----------------------------------------->| | Chunk | | | |<---------------|<-------------------------------OK Chunk--| | | | | | Figure 2: A typical PPSP bootstrap procedure 3.3 Streaming Modes The streaming technique is pull-based, i.e., the client peer requests the media chunks from serving peers and is responsible for handling the buffering that is necessary for the playback processes during the download of the media chunked files, turning this technique more robust to peer churn but still with acceptable latency for a smooth play-out. In Live streaming, all peers are interested in the media coming from an ongoing program, which means that all peers share nearly the same streaming content at a given point of time. Peers may store the live media for further distribution (known as time-shift TV), where the stored media is distributed in a VoD-like manner. In VoD, different peers watch different parts of the recorded media content during a past event. In this case, each peer keeps asking Cruz, et al. Expires December 2, 2011 [Page 10] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 other peers which media chunks are stored in which peers, and then gets the required media from certain/selected peers. 3.4 Chunk Scheduling The goal of chunk trading is receiving the stream smoothly (and with small delay) and to cooperate in the distribution procedure. Peers need to exchange information about their current status to enable scheduling decisions. The information exchanged refers to the state of the peer with respect to the flow, i.e., a map of which chunks are needed by a peer to smoothly play-out the stream. This task means: 1. sending chunk maps to other nodes with the proper timing, 2. receiving chunk maps from other nodes and merging the information in the local buffer map. 3. besides chunk map exchange, the signaling includes Status/Request/Select primitives used to trade chunks. The core of the scheduler, not described in this specification, is the algorithm used to choose the chunks to be exchanged and the peers to communicate with. 3.5 NAT Traversal It is assumed that all trackers must be in the public Internet. This document will not describe NAT Traversal mechanisms but the proposed protocol tries to enable flexible NAT Traversal. Future versions will consider the requirements raised by NAT. 3.6 Manifest File The Manifest file holds information about the content, i.e., describes the structure of the media, namely, the codecs used, the chunks, the number of layers (in case of SVC) or number of descriptions (in case of MDC), and the corresponding mapping within a container file system. The Manifest is a Well-Formed XML Document, encoded as double-byte Unicode. The Manifest is a composite schema that includes, as root Element, a StreamInfo field that encapsulates all the metadata required for the play-out of the media in groups of fields with elements corresponding to each component of the media (video, audio) streams, as well as other associated metadata (subtitles, text descriptions, etc.). The different elements may include Cruz, et al. Expires December 2, 2011 [Page 11] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 specific descriptor elements, like Video and Audio and respective attributes for each of the media types. An example of a XML manifest for a VoD scalable video content is the following (Figure 3): 123456abcd path/name some description Figure 3: XML Manifest for a VoD scalable video The Manifest file for P2P Streaming MUST contain Tracker information prior to its upload to the Service Tracker during the publishing procedure and can be compressed with GZIP file format [RFC 1952] in order to be used with HTTP compression [RFC 2616] for faster transmission times and less network bandwidth usage. The Client Media Player parses the downloaded Manifest file and, if it includes information for P2P Streaming, sends the file to the Peer via a HTTP POST and waits for the response in order to start requesting media chunks to decode and play-out. The Manifest file can also be used for direct download/stream (HTTP Streaming) from a specific server, and in this case, the file is not appended with the P2P Tracker information. The Client Media Player, in this case, just starts requesting media chunks from the HTTP Streaming server to decode and play-out. The Manifest file for Live Streaming has a similar structure but describes a sliding window of a small range of from the live program stream timeline (typically, 10 seconds of video). The sliding window is updated for every new encoded segment of the Cruz, et al. Expires December 2, 2011 [Page 12] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 program stream. An example of a XML manifest for a Live scalable video content is the following (Figure 4): 654321xyz TRUE 06:56:18 1258 path/name some description Figure 4: XML Manifest for a Live scalable video The naming convention used to identify the media chunks considers a sequencial numbering for the chunks, concatenated with the identifier of the content, tipically an alphanumeric string. For SVC and MDC contents, a "leveltype" and a "level_id" are added, being the media chunks named as follows: SVC/MDC: <-><->. other: <->. Where is a character with values L for SVC Layers and D for MDC descriptions, and is a numeric value identifying the layer (SVC) or description (MDC). Cruz, et al. Expires December 2, 2011 [Page 13] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 Examples of the naming convention for a content_id="A123456789" are as following: SVC: A123456789-L0-00000.h264 - chunk 0, layer 0 (base layer) SVC: A123456789-L1-00000.h264 - chunk 0, layer 1 (enhanced layer) MDC: A123456789-D0-0000.h264 - chunk 0, description 0 Audio AAC: A123456789-00000.aac Video MPEG: A123456789-00000.mp4 4 Messages syntax and processing The PPSP Peer Protocol messages follow the request and response standard formats for HTTP Request and Response messages [RFC2616]. 4.1 HTTP/XML Encoding A Request message is a standard HTTP Request generated by the HTTP Client Peer with the following syntax: / HTTP/1.1 Host: The HTTP Method and URI path (the Resource) indicates the operation requested. The current proposal uses only HTTP POST as a mechanism for the request messages. The Host header follows the standard rules for the HTTP 1.1 Host Header. The Response message is also a standard HTTP Response generated by the HTTP Serving Peer with the following syntax: HTTP/1.1 Content-Lenght: Content-Type: Content-Encoding: Cruz, et al. Expires December 2, 2011 [Page 14] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 The body for both Request and Response messages are encoded in XML for all the PPSP Peer Protocols messages, with the following schema (the XML information being method specific): *** *** ### ...XML information specific of the Method... In the XML body, the *** represents alphanumeric data and ### represents numeric data to be inserted. The corresponds to the method type for the message, the corresponds to the response method type of the message and the element uniquely identifies the transaction. The Response message MAY use Content-Encoding entity-header with "gzip" compression scheme [RFC2616] for faster transmission times and less network bandwidth usage. 4.2 Method Fields Table 1 and Table 2 define the valid string representations for the requests and responses, respectively. These values MUST be treated as case-insensitive. +--------------+--------------------------+ | PPSP Request | XML Request Value String | +--------------+--------------------------+ | GET_PEERLIST | GET_PEERLIST | | GET_CHUNKMAP | GET_CHUNKMAP | | GET_CHUNK | GET_CHUNK | | PEER_STATUS | PEER_STATUS | +--------------+--------------------------+ Table 1: Valid Strings for Requests Cruz, et al. Expires December 2, 2011 [Page 15] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 +----------------------+---------------------+--------------------+ | Response Method Name | HTTP Response | XML Response Value | | | Mechanism | | +----------------------+---------------------+--------------------+ | SUCCESSFUL (OK) | 200 OK | OK | | INVALID SYNTAX | 400 Bad Request | INVALID SYNTAX | | VERSION NOT | 400 Bad Request | VERSION NOT | | SUPPORTED | | SUPPORTED | | AUTHENTICATION | 401 Unauthorized | AUTHENTICATION | | REQUIRED | | REQUIRED | | MESSAGE FORBIDDEN | 403 Forbidden | MESSAGE FORBIDDEN | | OBJECT NOT FOUND | 404 Not Found | OBJECT NOT FOUND | | INTERNAL ERROR | 500 Internal Server | INTERNAL ERROR | | | Error | | | TEMPORARILY | 503 Service | TEMPORARILY | | OVERLOADED | Unavailable | OVERLOADED | +----------------------+---------------------+--------------------+ Table 2: Valid Strings for Responses 4.3 Message Processing When a PPSP Peer Protocol message is received in a peer, some basic processing is performed, regardless of the message type. Upon reception, a message is examined to ensure that it is properly formed. The receiver MUST check that the HTTP message itself is properly formed, and if not appropriate standard HTTP errors MUST be generated. The receiver must also verify that the XML body is properly formed. If the message is found to be incorrectly formed or the length does not match the length encoded in the header, the receiver MUST reply with an HTTP 400 response with a PPSP XML body with the Response method set to INVALID SYNTAX. 4.4 GET_PEERLIST Message The GET_PEERLIST message is sent from a client peer to a selected serving peer in order for a peer to refresh/update the list of active peers in the swarm. Cruz, et al. Expires December 2, 2011 [Page 16] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 The Request message uses a HTTP POST method with the following body: GET_PEERLIST *** *** ### The sender MUST properly form the XML body, MUST set the Method string to GET_PEERLIST, MUST set the PeerID to the PeerID of the peer, MUST set the SwarmID to the joined swarm identifier and randomly generate and set the TransactionID value. When receiving the GET_PEERLIST message, and if the message is well formed and accepted, the peer will search for the requested data and will respond to the requesting peer with an HTTP 200 OK message response with a PPSP XML payload SUCCESSFUL, as well as the peer list with PeerIDs (and respective IP Addresses) of peers that can provide the specific content. The response MUST have the same TransactionID value as the request. An example of the Response message structure is the following: Cruz, et al. Expires December 2, 2011 [Page 17] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 OK *** ### *** *** **** *** ### *** *** **** *** ### The element MAY contain multiple child elements. The element MAY contain multiple child elements with attributes "ip" and "port" corresponding to each of the network interfaces of the peer. The "ip" attribute can be expressed in dotted decimal format for IPv4 or 16-bit hexadecimal values (hh) separated by colons (:) for IPv6. The elements and have a string format, and together with the element of numerical integer format, form a set of information related to peer location. Cruz, et al. Expires December 2, 2011 [Page 18] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 4.5 GET_CHUNKMAP Message The GET_CHUNKMAP message is sent from a client peer to a selected serving peer in order to receive the map of chunks of a content (of a swarm identified by SwarmID) the other peer presently stores. The chunk map returned by the other peer lists ranges of chunks. The Request message uses a HTTP POST method with the following body: GET_CHUNKMAP *** *** ### The sender MUST properly form the XML body, MUST set the Method string to GET_CHUNKMAP, MUST set the PeerID to the PeerID of the peer, MUST set the SwarmID to the joined swarm identifier and randomly generate and set the TransactionID value. When receiving the GET_CHUNKMAP message, and if the message is well formed and accepted, the peer will search for the requested data and will respond to the requesting peer with an HTTP 200 OK message response with a PPSP XML payload SUCCESSFUL, as well as the map of chunks it currently stores of the specific content. The response MUST have the same TransactionID value as the request. The Response message is an HTTP 200 OK message with the following body, exemplified for a video component of a media clip: Cruz, et al. Expires December 2, 2011 [Page 19] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 OK ### *** *** ...(base64 string)... The element MAY contain multiple child elements. The element has an attribute "type" that indicates the type of media of the corresponding chunks. A element MAY contain multiple child elements with attributes "from" and "to" corresponding to ranges of contiguous chunks. The "from", "to", and "bitmapSize" attributes are expressed as integer number string format. The content corresponds to the chunk map, and is represented as base64 encoded string. 4.6 GET_CHUNK Message The GET_CHUNK message is sent from a client peer to a serving peer in order to request the delivery of media content chunks. The Request message uses a HTTP POST method with the following body: GET_CHUNK *** *** ### The sender MUST properly for the HTTP request for a POST method including the URI path (the Resource) of the chunk. The sender MUST also properly form the XML body, MUST set the Method string to GET_CHUNK, MUST set the PeerID to the PeerID of the peer, MUST set Cruz, et al. Expires December 2, 2011 [Page 20] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 the SwarmID to the joined swarm identifier and randomly generate and set the TransactionID value. +--------------+ +-------------+ | Peer (Leech) | | Peer (Seed) | +--------------+ +-------------+ | POST /path/name/123456789-L0-00000.h264 HTTP/1.1 | | Host: example.net | |------------------------------------------------------>| | | | | | GET_CHUNK | | *** | | *** | | ### | | | | | | | | HTTP/1.1 200 OK | | Content-Type: text/xml | | Transfer-Encoding: chunked | |<------------------------------------------------------| | | | 143 | | | | | | OK | | ### | | | | | | ### | | (### bytes of the video chunk) | | 0 | Figure 5: Example of GET_CHUNK message sequence (simplified) When receiving the GET_CHUNK message, and if the message is well formed and accepted, the peer will search for the requested data and will respond to the requesting peer with an HTTP 200 OK message response with a PPSP XML payload SUCCESSFUL, as well as the map of chunks it currently stores of the specific content. The Response message is an HTTP 200 OK message with the body, immediately followed by the chunk data transfer, as shown in Figure 5. The response MUST have the same TransactionID as the request. Cruz, et al. Expires December 2, 2011 [Page 21] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 4.7 PEER_STATUS Message The PEER_STATUS message is sent from a serving peer to a client peer to indicate its participation status. The information conveyed may include information related to chunk trading like "choke" (to inform the other peer of the intention to stop sending data to it) and "unchoke" (to inform the other peer of the intention to start/re- start sending data to it). The Request message uses a HTTP POST method with the following body: PEER_STATUS *** *** ### (choke/unchoke) The sender MUST properly form the XML body, MUST set the Method string to PEER_STATUS, MUST set the PeerID to the PeerID of the peer, MUST set the SwarmID to the joined swarm identifier and randomly generate and set the TransactionID value. When receiving the PEER_STATUS message, and if the message is well formed and accepted, the peer will respond to the requesting peer with an HTTP 200 OK message response with a PPSP XML payload SUCCESSFUL. If the status signal received is "choke" the peer will stop requesting chunks from the other peer until receiving an "unchoke" status signal. The only element currently defined in the request message is , assuming values of "choke" and "unchoke", but, in future, other values may be added. The Response message is an HTTP 200 OK message with the following body. OK ### The response MUST have the same TransactionID value as the request. Cruz, et al. Expires December 2, 2011 [Page 22] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 The only element currently defined in the response message is the , but, in future, other elements may be added, for example, containing statistical data or other primitives for chunk trading negotiation. 5 Security Considerations The security considerations will depend on the design of the PPSP peer protocol. Security will be considered in further version of this draft. 6 IANA Considerations There are presently no IANA considerations with this document. 7 Acknowledgments The authors would like to thank all the people participating in the EU FP7 project SARACEN for contributions and feedback to this document. SARACEN (Socially Aware, collaboRative, scAlable Coding mEdia distributioN), is a research initiative funded partially by the Information Society and Media Directorate General of the European Commission under the Seventh Framework programme (contract no. ICT- 248474). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the SARACEN project or the European Commission. The Response method names and some text describing them, was borrowed from [I-D.gu-ppsp-tracker-protocol]. 8 References 8.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Cruz, et al. Expires December 2, 2011 [Page 23] INTERNET DRAFT HTTP-based PPSP Peer Protocol May 31, 2011 [ISO.8601.2004] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, December 2004. 8.2 Informative References [I-D.ietf-ppsp-reqs] Zong, N., Zhang, Y., Avila, V., Williams, C., and L. Xiao, "P2P Streaming Protocol (PPSP) Requirements", draft-ietf-ppsp-reqs-02 (work in progress), February 2011. [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G., Seng, J., and Y. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)", draft-ietf-ppsp-problem-statement-01 (work in progress), January 2011. [I-D.ietf-ppsp-survey] Yingjie, G., Zong, N., Zhang, H., Zhang, Y., Lei, J., Camarillo, G., and L. Yong, "Survey of P2P Streaming Applications", draft-gu-ppsp-survey-02 (work in progress), March 2011. [I-D.gu-ppsp-tracker-protocol] Yingjie, G., Bryan, D., Zhang, Y., and H. liao, "PPSP Tracker Protocol", draft-gu-ppsp-tracker- protocol-04 (work in progress), May 2011. [refs.saracenwebpage] "SARACEN Project Website", http://www.saracen-p2p.eu/. 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 Joao Pedro Taveira Pinto Silva IST/INOV Phone: +351.966913777 Email: joao.taveira@inov.pt Cruz, et al. Expires December 2, 2011 [Page 24]