David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th 2010 PPSP Protocol Considerations

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th My Thoughts… Trying to share a picture of what a PPSP deployment might look like This comes from our work on our strawman peer protocol proposal, as well as the constraints of the charter When possible, want to reuse protocols. Where can we and what? –Short overview of the protocol details of BitTorrent These are my own (very early!) thoughts, so may be wrong, but hope to stimulate discussion

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th What are we trying to do? There are two basic protocols (or protocol operations) –Tracker protocol How to find other peers that share the information –Peer protocol How to get information from those peers once you have found them But we seem to be looking at two different tasks –Offline/timeshifted media (essentially file sharing) –Streaming/realtime media

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Tracker Protocol Need some way to locate the peers that are sharing same content Don’t have a direct protocol to reuse from IETF Basic idea is that tracker functionality is on a single server, but could be distributed (DHT) –Note that this is essentially a client-server protocol. Could distribute as a DHT underneath, but the tracker-peer operation is basically C/S –I’ve heard proposal to use RELOAD, this works if the tracker is made up of a distributed set of peers –Anaheim meeting indicated interest in tracker as a server, so seems RELOADs only application here is possibly as an implementation detail underneath or as an alternate distributed implementation

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th BitTorrent as a Model? Approach seems well suited to offline use case May not have all the information we want/need for streaming –Need to find peers “nearby” in the stream –Should tracker attempt to do this? –If not, many peers may need to be contacted to find one in “right place” (depending on window size, pause, etc) Possible issues –Security (or lack of) –HTTP approach is somewhat heavy –Do we want to incorporate metadata into tracker (not offline in torrent file)? Need to specify syntax for these metadata files

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Some BT Basics BT’s primary purpose/design is for file sharing (not originally designed for live streaming) Peers that share a particular file cluster together to share portions of a file form a swarm

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th BitTorrent Entities Peers: Hosts that hold some portion of the swarm are peers. Peers exchange blocks, and a set of blocks makes up a piece of the file –A Seed is a peer with the entire file Tracker: A central server that stores a mapping between a swarm and the peers participating in that swarm –Tracker doesn’t store which peers have which pieces, just list of the peers –Tracker is located offline…

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th File and Metadata Original person sharing the file splits it up into pieces, and performs an MD5 hash on each piece The list of pieces and their hashes, and the location of a tracker that will serve peers sharing this file are placed into a metadata file called a torrent Original user places torrent on a web server, and subscribes to tracker with all chunks, as the initial seed

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Example Startup 1) File is chopped up, MD5 sum generated Tracker Chunk1 Chunk2 Chunk3 … 2) Torrent file lists chunks, sums, and tracker to use for swarm Tracker Chunk1 Chunk2 Chunk3 … 3) Torrent file is stored on web server T P 4) Peer connects to Tracker with entire file as seed

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Example Join Swarm Tracker Chunk1 Chunk2 Chunk3 … 1) Peer connects to web site and obtains torrent file to locate tracker P 2) Peer connects to Tracker to find other peers P T P P P P 3) Peer connects to other peers in swarm and exchanges chunks

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Peer Exchange Peers exchange blocks or chunks, which are smaller than a piece described in the metadata. Once a whole piece is collected, can MD5 verify it. Peers have a simple gossip protocol between each other (generally unstructured, not a DHT) –Peers open a connection to peers that may have chunks they care about

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Peer Exchange, continued When a peer connects, it sends a bitfield message to peers indicating which chunks it has A peer can request a chunk with request, and the other peers sends it back in a piece message Once a peer has succeeded in downloading a piece, it advertises this to the other peers it is connected to with the have message. Interested/not interested and choked/not choked are used in flow control Also keep-alive message

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Protocol Details Regular HTTP is used to obtain the torrent from a web server The tracker protocol is also HTTP, essentially GET to ask for a list of peers/join swarm The peer protocol is a TCP wire protocol (binary)

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th BitTorrent References Official Protocol Specification (very limited!) is at Unofficial Specifications (much more detailed) at theory.org:

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Our (Strawman) Proposal New -01 version coming soon –Yingjie Gu, David Bryan, Yunfei Zhang, Hongluan Liao Currently propose binary protocol (but open) –Light weight, aesthetic considerations –Could also use HTTP with XML or something similar Messages to connect to a tracker/disconnect –Credential verification, verify peer-ID later used by peer protocol –Credential issuance/peer-ID assignment not (necessarily) by tracker Messages to join/leave a swarm (and get list of peers) –Currently can store location in stream/get peers at this location…may be hard to implement Diagnostics between peers and tracker, keep-alive messages, query list of swarms from tracker Will describe in detail in later talk

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Peer Protocol Considerations New transport is out of scope. –Offline and Streaming scenarios Need to reuse existing protocols SRTP/RTP for streaming. ??? For offline Should work of LEDBAT be leveraged here? Lightweight gossip protocol between peers –Typical for BT is peers, in an unstructured way –Is RELOAD suited for this, or will we need something lighter? Try a RELOAD usage and find out?

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th What might this look like? P T P P P Offline/Time Shifted Scenario New peer protocol (BT based?) to find peers, get metadata (not specific chunks) Lightweight gossip protocol between peers to find chunks (RELOAD usage or new?) Existing transport protocol to obtain chunks from peer (leverage LEDBAT?)

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th What might this look like? P T P P P Streaming Scenario New peer protocol (BT based?) to find peers, get metadata, where in stream peer is? Lightweight gossip protocol between peers to start/stop stream to other peers Existing transport protocol to stream the data (RTP/SRTP?)

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Conclusion May be many places where we can reuse existing protocols, but in some cases, using for things we haven’t done before –LEDBAT? –RELOAD for lightweight/gossip protocol (not DHT)? –New protocol for Tracker or HTTP with XML bodies or something similar?