1. 2: Application Layer1 Chapter 2 Application Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 Part 5: P2P

2. 2: Application Layer2 Chapter 2: Application layer r 2.1 Principles of network applications r 2.2 Web and HTTP r 2.3 FTP r 2.4 Electronic Mail  SMTP, POP3, IMAP r 2.5 DNS r 2.6 P2P applications r 2.7 Socket programming with UDP r 2.8 Socket programming with TCP

3. 2: Application Layer3 Pure P2P architecture r no always-on server r arbitrary end systems directly communicate r peers are intermittently connected and change IP addresses r Peers always send entire file to another peer  Some systems (like bit torrent) break files up into pieces. peer-peer

4. 2: Application Layer4 Pure P2P architecture r We’ll consider three examples:  File distribution  Searching for information  Case Study: Skype peer-peer

5. 5 File Distribution: Server-Client vs P2P Question : How much time to distribute file from one server to N peers? Distribution time: the time it takes to get a copy of the file to all N peers. Assumptions: 1. the internet core has abundant bandwidth therefore all bottlenecks are in network access. 2. Server and peers are not doing anything else on the internet.

6. 2: Application Layer6 File Distribution: Server-Client vs P2P Question : How much time to distribute file from one server to N peers? usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Server Network (with abundant bandwidth) File, size F u s : server upload bandwidth u i : peer i upload bandwidth d i : peer i download bandwidth

7. File Distribution: Server-Client vs P2P Question : How much time to distribute file from one server to N peers? 2: Application Layer7 Time to upload file from server for first peer: F/u s Time to upload file from server for second peer: F/u s Time to upload file from server for n th peer: F/u s … Time to download file to first peer: F/d 1 (could be long) Time to download file to second peer: F/d 2 The smaller d i the larger F/d i and the longer the download time. Could start downloading before entire file is uploaded by server

8. 2: Application Layer8 File distribution time: server-client usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Server Network (with abundant bandwidth) F r server sequentially sends N copies:  NF/u s time r client i takes F/d i time to download increases linearly in N (for large N) = d cs >= max { NF/u s, F/min(d i ) } i Time to distribute F to N clients using client/server approach

9. 2: Application Layer9 File distribution time: P2P usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Server Network (with abundant bandwidth) F r server must send one copy: F/u s time r client i takes F/d i time to download r NF bits must be downloaded (aggregate)  fastest possible upload rate: u s +  u i r In other words, if every node had a copy of the file r And every node uploaded the file simultaneously r Then the total rate of upload would be the sum of all the rates

10. File Distribution: Server-Client vs P2P Question : How much time to distribute file from one server to N peers? 2: Application Layer10 Time to upload file from server for first peer: F/u s Time to upload file from server for second peer: F/u s Time to upload file from server for n th peer: F/u s … Total Time to download file to first peer (from many other peers): F/d 1 (all the bits have to be downloaded) Time to download file to second peer: F/d 2 The smaller d i the larger F/d i and the longer the download time.

11. 2: Application Layer11 File distribution time: P2P usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Server Network (with abundant bandwidth) F r server must send one copy: F/u s time r client i takes F/d i time to download r NF bits must be downloaded (aggregate)  fastest possible upload rate: u s +  u i d P2P >= max { F/u s, F/min(d i ), NF/(u s +  u i ) } i

12. 2: Application Layer12 Server-client vs. P2P: example Client upload rate = u, F/u = 1 hour, u s = 10u, d min ≥ u s

13. 2: Application Layer13 File distribution: BitTorrent tracker: tracks peers participating in torrent torrent: group of peers exchanging chunks of a file obtain list of peers trading chunks peer r P2P file distribution

14. 2: Application Layer14 BitTorrent (1) r file divided into 256KB chunks. r peer joining torrent:  has no chunks, but will accumulate them over time  registers with tracker to get list of peers, connects to subset of peers (“neighbors”) r while downloading, peer uploads chunks to other peers. r peers may come and go r once peer has entire file, it may (selfishly) leave or (altruistically) remain

15. 2: Application Layer15 BitTorrent (2) Pulling Chunks r at any given time, different peers have different subsets of file chunks r periodically, a peer (Alice) asks each neighbor for list of chunks that they have. r Alice sends requests for her missing chunks  rarest first Sending Chunks: tit-for-tat r Alice sends chunks to four neighbors currently sending her chunks at the highest rate  re-evaluate top 4 every 10 secs r every 30 secs: randomly select another peer, starts sending chunks  newly chosen peer may join top 4  “optimistically unchoke”

16. 2: Application Layer16 BitTorrent: Tit-for-tat (1) Alice “optimistically unchokes” Bob (2) Alice becomes one of Bob’s top-four providers; Bob reciprocates (3) Bob becomes one of Alice’s top-four providers With higher upload rate, can find better trading partners & get file faster!

17. Distributed Hash Table (DHT) r DHT = distributed P2P database r Database has (key, value) pairs;  key: social security number; value: human name E.g., (123-45-6789, George Bush)  key: content type; value: IP address E.g., (Newsboys Shine, 203.17.123.38) r Peers query DB with key  DB returns values that match the key  Example: query with 123-45-6789 get “George Bush”  Example: query with “Newsboys Shine” get 203.17.123.38 r Peers can also insert (key, value) peers

18. How do we store the DB? r One central server  Early napster  Defeats the purpose in some ways r Randomly distribute pieces  Each peer maintains a list of the IP addresses of all participating peers.  Not scalable 2: Application Layer18

19. DHT Identifiers r Better: Assign integer identifier to each peer in range [0,2 n -1].  Each identifier can be represented by n bits. r Require each key in DB to be an integer in same range.  There are different types of keys, e.g., SSN or band name  Doesn’t matter: every key will be an integer in this range. r Problem: keys are not necessarily integers!  To get integer keys, hash original key.  eg, key = h(“Led Zeppelin IV”) = some integer.  Hash function can insure result is in our range  This is why they call it a distributed “hash” table

20. How to assign keys to peers? r Central issue:  Assigning (key, value) pairs to peers. i.e., which peer will store with (key, value) pairs?  Recall each peer is assigned an identifier r Rule: assign key to the peer that has the closest ID. r Convention in lecture: closest is the immediate successor of the key.

21. How to assign keys to peers? r Example: n=4;  Then all peer identifiers are in range [0, 15]  peers: 1,3,4,5,8,10,12,14;  key = 13, then successor peer = 14  Key = 8, then successor peer = 8  key = 15, then successor peer = 1

22. 1 3 4 5 8 10 12 15 Circular DHT (1) r Each peer only aware of immediate successor and predecessor. r “Overlay network”:  the peers form their own “network”  A successor/predecessor may be many hops away

23. Circle DHT (2) 0001 0011 0100 0101 1000 1010 1100 1111 Who’s resp for key 1110 ? I am Disadv: O(N) messages on avg (actually N/2) to resolve query, when there are N peers 1110 Define closest as closest successor Advantage: little info kept in each peer

24. Circular DHT with Shortcuts r Each peer keeps track of IP addresses of predecessor, successor, short cuts. r Reduced from 6 to 2 messages. r Possible to design shortcuts so O(log N) neighbors, O(log N) messages in query 1 3 4 5 8 10 12 15 Who’s resp for key 1110?

25. Peer Churn r Peer 5 abruptly leaves r Peer 4 detects; makes 8 its immediate successor; asks 8 who its immediate successor is; makes 8’s immediate successor its second successor. r What if peer 13 wants to join? 1 3 4 5 8 10 12 15 To handle peer churn, require each peer to know the IP address of its two successors. Each peer periodically pings its two successors to see if they are still alive.

26. 2: Application Layer26 P2P Case study: Skype r inherently P2P: pairs of users communicate. r proprietary application-layer protocol (inferred via reverse engineering) r hierarchical overlay with supernodes r Index maps usernames to IP addresses; distributed over SNs r Skype is proprietary but guess is that it uses DHT Skype clients (SC) Supernode (SN) Skype login server

27. 2: Application Layer27 Peers as relays r Problem when both Alice and Bob are behind “NATs”.  NAT prevents an outside peer from initiating a call to insider peer r Solution:  Using Alice’s and Bob’s SNs, Relay is chosen  Each peer initiates session with relay.  Peers can now communicate through NATs via relay