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

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Proposal New -01 version coming soon (quite a few changes) –Yingjie Gu, David A. Bryan, Yunfei Zhang, Hongluan Liao This is a basic overview, not a detailed description (can read draft shortly when we iterate for all details) Still very early work -- primary focus is exploring problems through design/early implementation A number of hard questions are being left open for WG input, and I’ll talk about those today This is by no means complete right now -- lots of work left to do!!! Authors are very interested in suggestions

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Encoding, Transport Currently, we have proposed a binary protocol –Light weight, low bandwidth for mobile devices –Basic ideas would apply to other encodings Right now, the transport is left unspecified -- looking for feedback from group –Since this is essentially a client-server like operation, preference is on a persistent secure connection approach (TLS/DTLS) May want a different approach if we do a distributed tracker –Is there a good reason to use DTLS (UDP)? Fragmentation mechanism borrowed from RELOAD (first/last bits, offset)

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Messages CONNECT/DISCONNECT –Associate with server, verify credentials –DISCONNECT removes from all swarms, leaves system JOIN/LEAVE –Participate in a particular swarm (streaming or file for VoD) –Possibly a JOIN_CHUNK to allow for specifying where in a live streaming (but big can of worms…) FIND –Locate a number of peers –Leaving room to specify a criteria (where in stream (if we allow JOIN_CHUNK), capacity, possibly certain layers –Quality (ALTO in the tracker, or do peers do ALTO?)

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Messages, Continued STATs messages –Send info to tracker –Tracker can also poll peers KEEPALIVE –Limit on live time for peers to tracker, so if no requests in a certain time, refresh connections –Another option is to expire either CONNECT or JOIN and require a subsequent call… QUERY –Search for swarms/list swarms (Tracker protocol or should this be something else?)

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Basic Shared Header | PPSP Tracker Protocol Token | | Version | Reserved | Method | | Transaction ID | | Fragmentation | | Message Length |

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Example Specific Request (JOIN) | PeerID (160 bits...) | SwarmID (128 bits...) | Expiration Time |

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Example Specific Response (FIND) | SwarmID (128 bits...) | NumPeers | Reserved | | Peer List (SEE BELOW) |

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Messages/Responses Transaction ID used for correlation/retransmission Responses are numeric codes, optionally with bodies (for example when requesting a list of peers) Currently a pure request/response protocol –No need for anything else so far

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Open Issues/Considerations Binary vs. text encoding Transport/security mechanism Need to define format for metadata describing the file Peer-IDs used in many messages, but assignment is offline. Do we want a version of connect that issues IDs? Response of list of peers depends on peer protocol used -- IP address vs. Peer-ID only NAT traversal needs to be considered

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Metafile Differs slightly for streaming/VoD VoD: –Needs to describe chunk format, number of chunks, break down (sizing), support for layered encodings, codec –MD5 sums of blocks (or collections of blocks) Streaming –Codec, chunk size, but likely some (number of chunks, MD5 sums don’t make sense) It is very important to get this right, but hard!

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Peer Protocol Impact If we use a DHT style peer protocol, with lookup, then at CONNECT time, the peers need to insert into the overlay –Tracker then only needs return peer-ID (after bootstrap to locate peer when connecting) If be use an unstrutured/gossip protocol, not clear this works –Random connection to 20 peers in a system of millions likely means you need to provide an address

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th NAT Traversal Easy for managed systems -- server is placed in a reachable location. Issue: unmanaged systems: –Can’t we guarantee tracker in public space Bigger issue: distributed tracker –Peers may very well be behind NATs –Fully distributed RELOAD may solve some of this –If just a few “super-peers”, how do we decide promotion (NAT detection is provably difficult/impossible…)

David A. Bryan, PPSP Workshop, Beijing, China, June 17th and 18th Conclusion New version coming soon, but this is still quite skeletal, much work remains Decoupling the design of the peer and tracker protocols may help with design, but some aspects are intertwined (for example peer list structure) New version of draft will have a “hard questions” section with the questions and a discussion of why they are hard –Hoping for agenda time at IETF-78 to discuss these