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 2010

Tracker Protocol Proposal

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

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


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)


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?)


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?)


Basic Shared Header

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PPSP Tracker Protocol Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Reserved | Method | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragmentation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Example Specific Request (JOIN)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerID (160 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SwarmID (128 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiration Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Example Specific Response (FIND)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SwarmID (128 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumPeers | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer List (SEE BELOW) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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


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


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!


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


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…)


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

david a. bryan, ppsp workshop, beijing, china, june 17th and 18th 2010 tracker protocol proposal

Documents