1. Server-client vs. P2P: example
Client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us 1

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

3. BitTorrent (1) file divided into 256KB chunks. 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”)
while downloading, peer uploads chunks to other peers.
peers may come and go
once peer has entire file, it may (selfishly) leave or (altruistically) remain 3

4. BitTorrent (2) Pulling Chunks
Sending Chunks: tit-for-tat
Alice sends chunks to four neighbors currently sending her chunks at the highest rate
re-evaluate top 4 every 10 secs
every 30 secs: randomly select another peer, starts sending chunks
newly chosen peer may join top 4
“optimistically unchoke”
Pulling Chunks
at any given time, different peers have different subsets of file chunks
periodically, a peer (Alice) asks each neighbor for list of chunks that they have.
Alice sends requests for her missing chunks
rarest first
Rarest first: from among the chunks she does not have, the chunks that are the rarest among the neighbors should be asked first. In this way, the rarest data gets distributed first.
The top 4 peers are called “unchoked”.
Every 30 seconds Alice randomly choose a new trading partner (peer) and initiate trading with that partner. If the 2 peers are happy with the trading, they will remain connected.
All other peers below top 5 do not get any data from Alice -- they 4

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

6. Distributed Hash Table (DHT)
DHT: distributed P2P database
database has (key, value) pairs;
key: ss number; value: human name
key: content type; value: IP address
peers query DB with key
DB returns values that match the key
peers can also insert (key, value) peers 6

7. DHT Identifiers
assign integer identifier to each peer in range [0,2n-1].
Each identifier can be represented by n bits.
require each key to be an integer in same range.
to get integer keys, hash original key.
e.g., key = h(“Led Zeppelin IV”)
this is why they call it a distributed “hash” table
To create integers out of the keys (such as “Led Zeppelin IV”), we will use a hash function that maps each key (e.g., a social security number or “Led Zeppelin IV”) to an integer in the range [0, 2^n -1]. A hash function is a many-to-one function for which two different inputs can have the same output (same integer), but the likelihood is extremely small. 7

8. How to assign keys to peers?
central issue:
assigning (key, value) pairs to peers.
rule: assign key to the peer that has the closest ID.
convention in lecture: closest is the immediate successor of the key.
e.g.,: n=4; peers: 1,3,4,5,8,10,12,14;
key = 13, then successor peer = 14
key = 15, then successor peer = 1
Given that each peer has an integer identifier and that each key is also an integer identifier n the same range, a natural approach is to assign each (key, value) pair to the peer whose identifier is closest to the key.
Suppose that n=4, hence [0,15].
Suppose that there are 8 peers: 1,3,4,5,8,10,12,14
How to insert a (key, value) pair?
Find the responsible peer (closest to the key value). But how to find a peer that is closest to the key? 8

9. Circular DHT (1) 1 3 4 5 8 10 12 15
Each peer is only aware of its immediate successor; e.g., peer 5 knows the IP address and identifier for peer 8 but does not necessarily know anything about any other peers that may be in the DHT.
“Overlay network” means that peers form an abstract logical network which resides above “underlay” computer network consisting of physical links, routers, and hosts.
In the figure there are 8 nodes and 8 links in the overlay.
By default a peer is aware of its predecessor because it is sending the messages.
each peer only aware of immediate successor and predecessor.
“overlay network” 9

10. Define closest as closest successor
Circular DHT (2)
0001
O(N) messages
on avg to resolve
query, when there
are N peers
Who’s resp
for key 1110 ?
I am
0011
1111
1110
0100
1110
If not responsible – keeps sending the question.
If responsible (node 12 in this case), it sends the response directly to the originator.
Although each peer is only aware of two neighboring peers, to find the node responsible for a key it takes:
N messages in the worst case and
N/2 on average.
Thus, there is a tradeoff between the # of neighbors each peer has to track and the # of messages that the DHT needs to send to resole a query.
Full mesh  1 query
Predecessor and successor  N/2 on average.
1110
1100
1110
0101
1110
Define closest as closest successor
1110
1010
1000 10

11. Circular DHT with Shortcuts1 3 4 5 8 10 12 15
Who’s resp
for key 1110?
Keep circular DHT as the foundation, but add “shortcuts” so that each peer keeps track not only of immediate successor ,but also of a relatively small number of shortcut peers scattered around the circle.
Example in the figure.
When receives a request, a peer sends a request either to the successor or to one of the shortcuts, whichever is closest to the key.
each peer keeps track of IP addresses of predecessor, successor, short cuts.
reduced from 6 to 2 messages.
possible to design shortcuts so O(log N) neighbors, O(log N) messages in query 11

12. Peer Churn peer 5 abruptly leaves1 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.
peer 5 abruptly leaves
Peer 4 detects; makes 8 its immediate successor; asks 8 who its immediate successor is; makes 8’s immediate successor its second successor.
What if peer 13 wants to join?
If 13 wants to join:
Assumption: knows only about 1’s IP address.
It then sends the question: “What will be 13’s predecessor and successor?”
Reaches 12 who realizes that it will be predecessor (because its current successor is larger than 13, it is15).
Peer 12 then sends this predecessor and successor information to peer 13.
13 can now join by making 15 its successor and by notifying peer 12 that it should change its immediate successor to 13.
BitTorrent uses the Kademlia DHT to create a distributed tracker.
In BitTorrent, the key is the torrent identifier and the value is the IP address of all the peers currently participating in the torrent. Thus, bu queuring the DHT with a torrent identifier, a newly arriving peer can query it for a list of other peers in the torrent. 12

13. P2P Case study: Skype inherently P2P: pairs of users communicate.
Skype clients (SC)
inherently P2P: pairs of users communicate.
proprietary application-layer protocol (inferred via reverse engineering)
hierarchical overlay with SNs
Index maps usernames to IP addresses; distributed over SNs
Skype
login server
Supernode
(SN)
Skype employs P2P techniques for 2 other important functions, namely, for user location and for NAT traversal. 13

14. Peers as relays problem when both Alice and Bob are behind “NATs”.
NAT prevents an outside peer from initiating a call to insider peer
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
When Alice and Bob sign in, they open a connection to their relays.
Once Alice calls Bob, the call is routed to Bob’s relay, and the relay then forwards the request to Bob. 14

15. Transport Layer Our goals:
understand principles behind transport layer services:
multiplexing/demultiplexing
reliable data transfer
flow control
congestion control
learn about transport layer protocols in the Internet:
UDP: connectionless transport
TCP: connection-oriented transport
TCP congestion control

16. Outline Transport-layer services Multiplexing and demultiplexing
Connectionless transport: UDP

17. Transport services and protocols
provide logical communication between app processes running on different hosts
transport protocols run in end systems
send side: breaks app messages into segments, passes to network layer
rcv side: reassembles segments into messages, passes to app layer
more than one transport protocol available to apps
Internet: TCP and UDP
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
logical end-end transport
network
data link
physical
network
data link
physical
application
transport
network
data link
physical

18. Transport vs. network layer
Household analogy:
12 kids sending letters to 12 kids
processes = kids
app messages = letters in envelopes
hosts = houses
transport protocol = parents
network-layer protocol = postal service
network layer: logical communication between hosts
transport layer: logical communication between processes
relies on, enhances, network layer services

19. outline Transport-layer services Multiplexing and demultiplexing
Connectionless transport: UDP

20. Multiplexing/demultiplexing
Multiplexing at send host:
Demultiplexing at rcv host:
delivering received segments
to correct socket
gathering data from multiple
sockets, enveloping data with
header (later used for
demultiplexing)
= socket
= process
application
transport
network
link
physical P1 P2 P3 P4
host 1
host 2
host 3

21. How demultiplexing works
host receives IP datagrams
each datagram has source IP address, destination IP address
each datagram carries 1 transport-layer segment
each segment has source, destination port number (recall: well-known port numbers for specific applications)
host uses IP addresses & port numbers to direct segment to appropriate socket
32 bits
source port #
dest port #
other header fields
application
data
(message)
TCP/UDP segment format

22. Connectionless demultiplexing
When host receives UDP segment:
checks destination port number in segment
directs UDP segment to socket with that port number
IP datagrams with different source IP addresses and/or source port numbers directed to same socket
Create sockets with port numbers:
DatagramSocket mySocket1 = new DatagramSocket(99111);
DatagramSocket mySocket2 = new DatagramSocket(99222);
UDP socket identified by two-tuple:
(dest IP address, dest port number)

23. Connectionless demux (cont)
DatagramSocket serverSocket = new DatagramSocket(6428);
Client
IP:B P2
client
IP: A P1 P3
server
IP: C
SP: 6428
DP: 9157
SP: 9157
DP: 6428
DP: 5775
SP: 5775
SP provides “return address”

24. Connection-oriented demux
TCP socket identified by 4-tuple:
source IP address
source port number
dest IP address
dest port number
recv host uses all four values to direct segment to appropriate socket
Server host may support many simultaneous TCP sockets:
each socket identified by its own 4-tuple
Web servers have different sockets for each connecting client
non-persistent HTTP will have different socket for each request

25. Connection-oriented demux (cont)P1
client
IP: A P4 P5 P6 P2 P1 P3
SP: 5775
DP: 80
S-IP: B
D-IP:C
SP: 9157
SP: 9157
DP: 80
DP: 80
Client
IP:B
server
IP: C
S-IP: A
S-IP: B
D-IP:C
D-IP:C

26. Outline Transport-layer services Multiplexing and demultiplexing
Connectionless transport: UDP

27. UDP: User Datagram Protocol [RFC 768]
“no frills,” “bare bones” Internet transport protocol
“best effort” service, UDP segments may be:
lost
delivered out of order to app
connectionless:
no handshaking between UDP sender, receiver
each UDP segment handled independently of others
Why is there a UDP?
no connection establishment (which can add delay)
simple: no connection state at sender, receiver
small segment header
no congestion control: UDP can blast away as fast as desired

28. UDP: more other UDP uses often used for streaming multimedia apps
loss tolerant
rate sensitive
other UDP uses
DNS
SNMP
reliable transfer over UDP: add reliability at application layer
application-specific error recovery!
32 bits
source port #
dest port #
Length, in
bytes of UDP
segment,
including
header
length
checksum
Application
data
(message)
UDP segment format

29. UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
Sender:
treat segment contents as sequence of 16-bit integers
checksum: addition (1’s complement sum) of segment contents
sender puts checksum value into UDP checksum field
Receiver:
compute checksum of received segment
check if computed checksum equals checksum field value:
NO - error detected
YES - no error detected. But maybe errors nonetheless? More later ….

30. Internet Checksum Example
Note
When adding numbers, a carryout from the most significant bit needs to be added to the result
Example: add two 16-bit integers
Kurose and Ross forgot to say anything about wrapping the carry and adding it to low order bit
wraparound
sum
checksum

31. Outline Transport-layer services Multiplexing and demultiplexing
Connectionless transport: UDP
Principles of reliable data transfer