* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ppsp Status Pages

Peer to Peer Streaming Protocol (Concluded WG)
Tsv Area: Zaheduzzaman Sarker, Martin Duke | 2010-Mar-24 — 2016-Jan-13 

2016-01-13 charter

Peer to Peer Streaming Protocol (ppsp)


 Current Status: Active

     Ning Zong <zongning@huawei.com>
     Yunfei Zhang <hishigh@sina.com>

 Transport Area Directors:
     Spencer Dawkins <spencerdawkins.ietf@gmail.com>
     Martin Stiemerling <mls.ietf@gmail.com>

 Transport Area Advisor:
     Martin Stiemerling <mls.ietf@gmail.com>

 Mailing Lists:
     General Discussion: ppsp@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/ppsp
     Archive:            https://mailarchive.ietf.org/arch/browse/ppsp/

Description of Working Group:

    The Peer-to-Peer Streaming Protocol (PPSP) working group develops two
    signaling and control protocols for a peer-to-peer (P2P) streaming
    system for transmitting live and time-shifted media content with near
    real-time delivery requirements.

    Two kinds of nodes exist in the targeted P2P streaming system, i.e.,
    "peers" and "trackers". Peers are nodes that are actively sending and
    receiving streamed media content, and include both statically connected
    hosts as well as mobile devices with connectivity and IP addresses that
    change over time. The set of peers that are participating in a streaming
    session will dynamically change over time. Trackers are well-known nodes
    with stable connectivity that maintain meta information about the
    streamed content and the dynamic peer set. Trackers can be organized in
    centralized or distributed ways.

    The PPSP WG designs a protocol for signaling and control between
    trackers and peers (the PPSP "tracker protocol") and a signaling and
    control protocol for communication among the peers (the PPSP "peer
    protocol"). The two protocols enable peers to receive streaming data
    within the time constraints required by specific content items. The
    tracker protocol handles the initial and periodic exchange of meta
    information between trackers and peers, such as peer lists and content
    information. The peer protocol controls the advertising and exchange of
    media data availability between the peers.

    It is envisioned that the tracker protocol will be modeled as a
    request/response protocol between peers and trackers, and will carry
    information needed for the selection of peers suitable for real-time
    streaming. The peer protocol is envisioned to be modeled as a
    gossip-like protocol with periodic, pairwise exchanges of neighbor and
    media chunk availability information. Both protocols will be carried
    over TCP (or UDP, when delivery requirements cannot be met by TCP),
    likely in combination with ICE for NAT traversal support. Perfect
    privacy protection is a good feature to have but not a mandatory
    requirement for the peer and tracker protocols. The WG will consider to
    use existing protocols as design base for the tracker and peer

    Developing mechanisms for searching trackers that contain a specific
    media item is out of the scope of this WG. Additionally, the WG will
    work under the assumption that trackers are logically centralized
    entities (e.g., a single server or a server farm performing DNS-based
    local balancing). However, as far as it is possible, the WG will not
    make design decisions that could preclude the use of distributed
    trackers in the future (e.g., DHT-based trackers).

    A peer looking for a media chunk uses the tracker and peer protocols to
    locate a remote peer (or peers) that can provide it with that media
    chunk. Obtaining the media chunk from the remote peer will involve some
    type of signaling exchange plus the actual media transfer. The first
    task for this WG will be to decide which signaling and media transfer
    protocols will be used. The WG will consider existing protocols and, if
    needed, identify potential extensions to these protocols. The WG will
    consider the interactions between these protocols and the peer protocol
    (e.g., avoiding duplicate NAT traversal procedures). Examples of
    signaling protocols to be considered are SIP, RTSP, and HTTP. Examples
    of media transfer protocols to be considered are RTP and HTTP.

    PPSP is not chartered to work on media transmission protocols, media
    encoding techniques or other components of a P2P streaming system such
    as playout, scheduling and control, etc.

    The work items of the PPSP WG are:

    (1) A "problem statement" document that gives an overview of the
    proposed P2P streaming system, motivates the desire for
    standardized protocols, defines the envisioned scope of those
    standardized components and discusses common terminologies and

    (2) A "requirements" document that details the specific functional,
    operational and performance requirements of the two PPSP

    (3) An "architectural survey" document that summarizes current P2P
    streaming architectures, in particular tracker-based P2P
    streaming systems, and highlights best current practices.

    (4) A detailed specification of the PPSP peer protocol.

    (5) A detailed specification of the PPSP tracker protocol.

    (6) A "usage guide" that describes how the two PPSP protocols and
    existing IETF protocols, such as P2PSIP or ALTO, can be combined
    to create a deployable operational P2P streaming system. This
    document may also discuss variants of such a system that, for
    example, use layered media encoding and related media chunk
    descriptions in the peer protocol for more robust streaming.

    The work items of the PPSP WG interacts with the work performed in other
    Whenever extensions or modification to the protocols developed in other
    WGs are deemed necessary, PPSP shall communicate and discuss the
    requirements for such extensions with the relevant WGs. PPSP is not
    chartered to design and specify such changes.

Goals and Milestones:
  Done     - Submit problem statement to IESG as Informational
  Done     - Submit requirements document to IESG as Informational
  Done     - Submit PPSP peer protocol to IESG as Proposed Standard
  Done     - Submit PPSP tracker protocol to IESG as Proposed Standard

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/ppsp/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -