1 / 19

PPSP Protocol Considerations

PPSP Protocol Considerations. 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?

bazyli
Download Presentation

PPSP Protocol Considerations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PPSP Protocol Considerations

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

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

  8. 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

  9. 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 3) Torrent file is stored on web server Tracker Chunk1 Chunk2 Chunk3 … T P 4) Peer connects to Tracker with entire file as seed

  10. Example Join Swarm 1) Peer connects to web site and obtains torrent file to locate tracker Tracker Chunk1 Chunk2 Chunk3 … P T P 2) Peer connects to Tracker to find other peers P 3) Peer connects to other peers in swarm and exchanges chunks P P P

  11. 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

  12. 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

  13. 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)

  14. BitTorrent References • Official Protocol Specification (very limited!) is at http://bittorrent.org/beps/bep_0003.html • Unofficial Specifications (much more detailed) at theory.org: http://wiki.theory.org/BitTorrentSpecification

  15. 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

  16. 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 20-50 peers, in an unstructured way • Is RELOAD suited for this, or will we need something lighter? • Try a RELOAD usage and find out?

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

  18. What might this look like? Streaming Scenario T New peer protocol (BT based?) to find peers, get metadata, where in stream peer is? P P Lightweight gossip protocol between peers to start/stop stream to other peers P Existing transport protocol to stream the data (RTP/SRTP?) P

  19. 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?

More Related