draft-gu-ppsp-tracker-protocol-02

1. draft-gu-ppsp-tracker-protocol-02 Y. Gu, D. A. Bryan, Y. Zhang, H. Liao IETF-79, Beijing China, November 12, 2010

2. Overview of Proposal • Protocol for exchanging information between tracker and peers, supporting mechanisms for the following: • Connect/Disconnect from a system • Join/Leave a swarm or channel • Find peers participating in a swarm or channel • Query or report statistics among tracker and peers • Keep alive message • Intended for centralized tracker, but protocol could easily be used among peers in a cooperative, DHT-based approach • Minor changes since -01, most notably used Peer-IDs vs. IP address (have now changed this idea…more in peer protocol draft)

3. 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 • Given a swarm, 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?)

4. Messages, Continued • STATs messages • STAT_QUERY/STAT_REPORT • Send info to tracker / query about other peers • 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 (do we need this?) • Search for swarms/list swarms (Tracker protocol or should this be something else?) • Not currently in the draft

5. Metafiles • 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! • Assuming this is the right place, but possibly between peers? • Currently nothing specifically proposed • Plan to add for -03. Looking for feedback/suggestions

6. Open Issues/Considerations • Binary vs. text encoding • Authors see this as less important than getting messages right, but would like to get sense of group • Transport/security mechanism • Likely certificate-based • Need to define format for metadata describing the file • Peer-IDs used in many messages, but assignment is offline. Do we want an (optional) version of connect that issues IDs? • NAT traversal needs to be fleshed out in draft

7. Open Issues/Considerations • Where to put the Peer Status in the Tracker? • Connection between swarm and status • PPSP Peer itself: Status information is stored in peer itself without involving Tracker. Reduces storage and signaling cost of Tracker, but optimized peer selection is done among PPSP peers. • Static status info only on Tracker: Store static info for peers w/swarm list, but need to contact peers to get ephemeral data • All status info on Tracker: Store all info for peers w/swarm list. This could be very expensive to store and update, particularly if you participate in many swarms.