The PPSP could easily be one of these groups were we spend the first few years trying to chooses which protocol to start with in various places. That would just remove the will to do anything in the group. I have been lurking and watching this work from the beginning and it seems like there are probably many things that most the participants agree to that we could just nail down in the charter. Doing so would help get the work done faster and provide others a clear idea that had not been been participating a much clearer idea of what this work is about. For example: Centralized or distributed trackers. My belief is that most the folks want to do a centralized tracker. On a side note, I think they would be hard to do a distributed one before a centralized as centralized is much easier. The obvious protocol to use for a centralized one is to add the needed extensions to the HTTP based version of bittorrent tracker protocol. If they want to do a distributed one, RELOAD would meet the needs and at least be worth looking at. Similarly for the media transfer, I suspect that many people would be happy with RTP. It's hard to imagine anything else given the end goal for this. I guess one could argue for a new protocol or a protocol that transferred data tunneled in the peer signaling protocol. The peer signing protocol needs to be able to set up the RTP sessions and work thought NATs. I think the NAT traversal scheme will end up being ICE or something that more or less amounts to ICE with no TURN option given the deployment models. Both RTSP and SIP are candidates here. In some ways at first glance, RTSP might seem simpler. But a bunch of that simplicity comes from the model of it being deployed on server all clients can easily reach without nat nightmares and less negotiation. Much of SIP complexity comes form too many intermediaries and forking which would not apply in this case. We will have to add a bunch to RTSP to get it to work or subtract some SIP to get it to work. Not an easy call and not a call that the WG is in a great position to sort out. I'd love to hear others thought on it. The alternative to the RTSP/SIP approach is to replace the signaling and SDP with a capabilities something more like the Advertisement / Proposal architecture the Jon and I have been discussion (See draft-peterson-sipcore-advprop ). There are a few other topics which are not addressed in this charter that worry me a lot. The currently protocols being proposed and related discussion does not seem to address what is the incentive for anyone to serve content. It's clear why you would receive but not clear why you would bother to transmit. Bittorrent put a lot of effort into this and IMHO got it "right enough" that the system is very successful. I worry about it in this work. A second topic is that the desired privacy properties of the system are also pretty vague. If we are not clear about these in the beginning, we run the risk of getting very bogged down in arguing about them as the protocol starts to get close to done. To try and help get things moving along, I have proposed charter bellow that is very conservative . As an individual, I would probably have a slight preference for a more risky approach than the proposal below but . ------------------------------------------------ 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. The working group is only addressing centralized trackers and not the distributed tracker. 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. The tracker protocol will be modeled as much as possible to match the exiting bittorrent protocol with appropriate extensions for to cary information that is needed for selection of a peer suitable for real time streaming. Media descriptions will use the syntax and semantics from SDP where that is possible. The peer protocol will be be an extension of SIP and use ICE for NAT traversal. RTP will be used for the encoding and transmission of the media content between peers. 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 concepts. (2) A "requirements" document that details the specific functional, operational and performance requirements of the two PPSP protocols. (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 ALTO, can be combined to create a deployable operational P2P streaming system. This document will also discuss use of 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 IETF WGs, including SIPCORE, AVT, ALTO, LEDBAT and MMUSIC. 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 but is not charted to make such changes. Goals and Milestones: Sep 2010 Submit problem statement to IESG as Informational Dec 2010 Submit architectural survey to IESG as Informational Dec 2010 Submit requirements document to IESG as Informational Aug 2011 Submit PPSP peer protocol to IESG as Proposed Standard Aug 2011 Submit PPSP tracker protocol to IESG as Proposed Standard Dec 2011 Submit usage guide to IESG to IESG as Informational