CS433/533Computer Networks
Lecture 15
Intro to Transport Layer
10/17/2013
1
2
Outline
Admin and recap Overview of transport layer UDP Reliable data transfer, the stop-and-wait
protocol
3
Admin
Namratha will send an email to give more details on Assignment one P3 quad-core solution
Assignment three questions
4
Recap: Content Lookup
Example unstructured p2p systems Napster (central query server) Gnutella (decentralized, flooding) Freenet (search by routing)
Advantages of unstructured p2p algorithms tend to be simple
Disadvantages hard to make performance guarantee failure even when files exist
5
Recap: The Computer Networks Distributed Search Question
Question: what kind of long distance links to maintain so that distributed network search is effective?
Assume that each node has a fixed # (say p distance away) local links a small # (say a total of q) long-distance links s.t. the
probability of a link between nodes x and y is some () inverse-power of the distance d(x, y) of x and y
A: α should be the dimension
6
Recap: Distributed Search
In other words, a guideline on long-distance links: roughly the same number of nodes in each region A1, A2, A4, A8, where A1 is the set of nodes who are one lattice step away, A2 is those two steps away, A4 is four steps away…
probability is proportional to (lattice steps)-d
7
Recap: Small World
Saul Steinberg; View of World from 9th Ave
Distributed Hash Tables (DHT)
In 2000-2001, academic researchers jumped on to the P2P bandwagon
Motivation: frustrated by popularity of all these “half-
baked” P2P apps. We can do better! (so they said)
guaranteed lookup success for data in system provable bounds on search time (motivated
by the Kleinberg observation) Examples
CAN, Chord• See optional slides at the end of lecture on Tuesday
Summary: P2P
Many issues remaining, e.g., Streaming ISP/P2P integration …
9
10
Outline
Recap Overview of transport layer
11
Transport Layer vs. Network Layer
Provide logical communication between app’ processes
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
Transport vs. network layer services: Network layer: data transfer
between end systems Transport layer: data transfer
between processes• relies on, enhances network
layer services
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
12
Transport Layer Services and Protocols Reliable, in-order delivery (TCP)
multiplexing reliability and connection setup congestion control flow control
Unreliable, unordered delivery: UDP multiplexing
Services not available: delay guarantees bandwidth guarantees
13
Transport Layer: Road Ahead
Transport overview (class 1, today): transport layer services connectionless transport: UDP reliable data transfer using stop-and-wait sliding window reliability
Sliding window and TCP (class 2): Connection management TCP reliability
Congestion control and AIMD (class 3)
TCP/Reno, TCP/Vegas, TCP in 3G/4G networks (class 4)
The Primal/Dual framework, Nash Bargaining solution (class 5)
14
Outline
Admin and recap Overview of transport layer UDP Reliable data transfer, the stop-and-go
protocols
UDP: User Datagram Protocol [RFC 768]Often used for
streaming multimedia apps loss tolerant rate sensitive
Other UDP usesDNSSNMP
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksumLength, in
bytes of UDP
segment,including
header
UDP Checksum
Sender: treat segment contents
as sequence of 16-bit integers
checksum: addition of segment contents to be zero
sender puts checksum value into UDP checksum field
Receiver: compute checksum of
received segment compute sum of segment
and checksum; check if sum zero NO - error detected YES - no error detected.
But maybe errors nonetheless?
Goal: end-to-end detection of “errors” (e.g., flipped bits) in transmitted segment
One’s Complement Arithmetic
UDP checksum is based on one’s complement arithmetic one’s complement was a common representation of
signed numbers in early computers
One’s complement representation bit-wise NOT for negative numbers example: assume 8 bits
• 00000000: 0• 00000001: 1• 01111111: 127 • 10000000: ?• 11111111: ?
addition: conventional binary addition except adding any resulting carry back into the resulting sum
• Example: -1 + 2
17
UDP Checksum: Algorithm
Example checksum:
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
wraparound
sumchecksum
- For fast implementation of computing UDP checksum, see http://www.faqs.org/rfcs/rfc1071.html
UDP Checksum: Coverage
Calculated over: A pseudo-header
IP Source Address (4 bytes)
IP Destination Address (4 bytes)
Protocol (2 bytes) UDP Length (2 bytes)
UDP header
UDP data
20
Outline
Admin and recap Overview of transport layer UDP Reliable data transfer
21
Principles of Reliable Data Transfer Important in app., transport, link layers top-10 list of important networking topics!
Reliable Data Transfer
22
23
Reliable Data Transfer: APIs
sendside
receiveside
rdt_send(): called from above, (e.g., by app.)
udt_send(): called by rdt,to transfer packet over unreliable channel to
receiver
rdt_rcv(): called from below; when packet arrives on rcv-side
of channel
deliver_data(): called by rdt to deliver data to
upper
24
Reliable Data Transfer: Getting StartedWe’ll: incrementally develop sender, receiver
sides of reliable data transfer protocol (rdt) consider only unidirectional data transfer
but control info will flow on both directions!
use finite state machines (FSM) to specify sender, receiver
state1
state2
event causing state transitionactions taken on state transition
state+next event: uniquely
determines next state and actions
eventactions
25
Outline
Admin and recap Overview of transport layer UDP Reliable data transfer
perfect channel
26
Rdt1.0: reliable transfer over a reliable channel
separate FSMs for sender, receiver: sender sends data into underlying channel receiver reads data from underlying channel
Wait for call from above packet = make_pkt(data)
udt_send(packet)
rdt_send(data)
extract (packet,data)deliver_data(data)
Wait for call from
below
rdt_rcv(packet)
sender receiver
27
Potential Channel Errors
bit errors
loss (drop) of packets
reordering or duplication
Characteristics of unreliable channel will determine the complexity of a reliable data transfer protocol (rdt).
28
Outline
Admin and recap Overview of transport layer UDP Reliable data transfer
o perfect channel channel with only bit errors
29
Rdt2.0: Channel With Bit Errors
Underlying channel may flip bits in packet
New mechanisms in rdt2.0 (beyond rdt1.0): receiver error detection: recall: UDP checksum to
detect bit errors sender retransmission receiver feedback: control msgs (ACK,NAK) rcvr-
>sender• acknowledgements (ACKs): receiver explicitly tells sender that
pkt received OK• negative acknowledgements (NAKs): receiver explicitly tells
sender that pkt had errors– sender retransmits pkt on receipt of NAK
30
rdt2.0: FSM Specification
Wait for data udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Wait for data
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
sender
receiver
Wait for ACK or
NAK
snkpkt = make_pkt(data, checksum)udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
31
rdt2.0: Operation with No Errors
Wait for data
snkpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Wait for ACK or
NAK
Wait for data
rdt_send(data)
32
rdt2.0: Error Scenario
Wait for data
snkpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Wait for ACK or
NAK
Wait for data
rdt_send(data)
33
Big Picture of rdt2.0sender
data (n)
receiver
data (n)
ACK
data (n+1)
waiting for N/ACK
waitingfor data
NACK
(data(n) NACK)*data(n)ACK
34
rdt2.0 is Incomplete!
What happens if ACK/NAK corrupted? Although sender receives feedback, but doesn’t
know what happened at receiver!
sender
data (n)waiting
for N/ACK ?
35
Two Possibilities
sender
data (n)
receiver
data (n)
waiting for
N/ACK waitingfor data
NACK
sender receiver
waiting for
N/ACK ACK
data (n+1)
data (n)
deliver
deliver
Wait for data udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
sender
Wait for ACK or
NAK
snkpkt = make_pkt(data, checksum)udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
It is always harder to deal with control
message errors than data message errors
36
Handle Control Message Corruption Sender can’t do anything even if the
control pkt is corrupted The pkt might be an NACK
If it just retransmits: possible duplicate
Handling duplicates: sender adds sequence
number to each pkt sender retransmits current
pkt if ACK/NAK garbled receiver discards (doesn’t
deliver up) duplicate pkt
sender sends one packet, then waits for receiver response
stop and wait
37
rdt2.1b: Sender, Handles Garbled ACK/NAKs
Wait for pkt n from
above
Wait for ACK or
NAK
sndpkt = make_pkt(n, data, checksum)udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )
sndpkt = make_pkt(n+1, data, checksum)udt_send(sndpkt)
rdt_send(data)
Wait for ACK or
NAK
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
Wait for pkt n+1 from
above
38
rdt2.1b: Receiver, Handles Garbled ACK/NAKs
Wait for n from below
Wait for n+1 from
below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq(n, rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && ! has_seq(n,rcvpkt)
sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
39
rdt2.1b: Summary
Sender: seq # added to pkt must check if received ACK/NAK corrupted
Receiver: must check if received packet is duplicate
by checking if the packet has the expected pkt seq #
40
Another Look at rdt2.1bsender
data (n)
receiver
ACK
data 1 (n+1)
waiting for n
sending n
waiting n+1
sendingn+1
waiting for n+2
NACK
data (n)
data (n)
ACK
41
State Relationship of rt2.1b
s0 senders1 s2
receiverw0 w1 w2 w3
w3
first time
rcvs 0
first timercvsack 0
w0 w1 w2
W1: wait for data for seq. 1S1: sending data (waiting ACK) for seq. 1
State invariant:- Receiver’s state leads: if it is waiting for seq #n, sender’s state can be sending either
seq#n-1or seq#n
42
rdt2.1c: Sender, Handles Garbled ACK/NAKs: Using 1 bit
Wait for call 0 from
above
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)
rdt_send(data)
Wait for ACK or
NAK udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )
sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
Wait for call 1 from
above
Wait for ACK or NAK 1
43
rdt2.1c: Receiver, Handles Garbled ACK/NAKs: Using 1 bit
Wait for 0 from below
sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
Wait for 1 from below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)
44
rdt2.1c: Discussion
Sender: state must “remember
” whether “current” pkt has 0 or 1 seq. #
Receiver: must check if
received packet is duplicate state indicates whether
0 or 1 is expected pkt seq #
45
A Flavor of Protocol Correctness Analysis: rdt2.1c Combined states of sender, receiver and channel Assume the sender always has data to send
0 0 00 0 N 0 1 A
1 1 11 0 A 1 1 N
sender state: sending 0 and waiting for ACK
channel state: packet seq#
corrupt ok corrupt
okok
corrupt
ok
receiver state: waiting for 0 0 1 0 0 1 N
corrupt
ok
1 0 0corrupt
1 0 N
corrupt
ok
46
rdt2.2: a NAK-free protocol
Same functionality as rdt2.1c, using ACKs only
Instead of NAK, receiver sends ACK for last pkt received OK receiver must explicitly include seq # of pkt being
ACKed
Duplicate ACK at sender results in same action as NAK: retransmit current pkt
47
rdt2.2: Sender, Receiver Fragments
Wait for call 0 from
above
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)
Wait for ACK
0
sender FSMfragment
Wait for 0 from below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK,0, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt))
sndpkt=make_pkt(ACK,1, chksum)udt_send(sndpkt)
receiver FSMfragment
48
Outline
Review Overview of transport layer UDP Reliable data transfer
o perfect channelo channel with bit errors channel with bit errors and losses
49
rdt3.0: Channels with Errors and Loss
New assumption: underlying channel can also lose packets (data or ACKs) checksum, seq. #,
ACKs, retransmissions will be of help, but not enough
Q: how to deal with loss?
Approach: sender waits “reasonable” amount of time for ACK
requires countdown timer retransmits if no ACK
received in this time if pkt (or ACK) just delayed
(not lost): retransmission will be
duplicate, but use of seq. # ’s already handles this
receiver must specify seq # of pkt being ACKed
50
rdt3.0 Sender
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer
Wait for
ACK0
rdt_send(data)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)
stop_timer
Wait for call 0 from
above
Wait for call 1 from
above
sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer
rdt_send(data) rdt_rcv(rcvpkt)
udt_send(sndpkt)start_timer
timeout
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )
rdt_rcv(rcvpkt)
Wait for
ACK1
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,0) )
stop_timer
udt_send(sndpkt)start_timer
timeout
51
rdt3.0 in Action
Question to think about: How to determine a good timeout value?
52
rdt3.0 in Action
53
rdt3.0sender
data 0 (n-1)
receiver
data 0 (n-1)
ACK for 0 (n-1)
data 1 (n)
waiting for 0(n-1)
sending 0 (n-1)
waiting for 1(n)
sending 1(n) waiting
for 0(n+1)
ACK for 0 (n-1)
State consistency:
When receiver’s state is waiting n, the state of the sender is either sending for n-1 or sending for n
When sender’s state is sending for n, receiver’s state is waiting for n or n + 1
54
rdt3.0: Stop-and-Wait Operation
first packet bit transmitted, t = 0
sender receiver
RTT
last packet bit transmitted, t = L / R
first packet bit arriveslast packet bit arrives, send ACK
ACK arrives, send next packet, t = RTT + L / R
What is Usender: utilization – fraction of time sender busy sending?
Assume: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet
55
Performance of rdt3.0
rdt3.0 works, but performance stinks Example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:
Ttransmit
= 8kb/pkt10**9 b/sec
= 8 microsec
1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
network protocol limits use of physical resources !
U sender
= .008
30.008 = 0.00027
microseconds
L / R
RTT + L / R =
L (packet length in bits)R (transmission rate, bps)
=
56
A Summary of Questions
How to improve the performance of rdt3.0?
What if there are reordering and duplication?
How to determine the “right” timeout value?
57
Outline
Review Overview of transport layer UDP Reliable data transfer
o perfect channelo channel with bit errorso channel with bit errors and losses sliding window: reliability with throughput
58
Sliding Window Protocols: PipeliningPipelining: sender allows multiple, “in-flight”, yet-to-
be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver
59
Pipelining: Increased Utilization
first packet bit transmitted, t = 0
sender receiver
RTT
last bit transmitted, t = L / R
first packet bit arriveslast packet bit arrives, send ACK
ACK arrives, send next packet, t = RTT + L / R
last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK
U sender
= .024
30.008 = 0.0008
microseconds
3 * L / R
RTT + L / R =
increase utilizationby a factor of 3!
Question: a rule-of-thumb window size?
60
Forms of Pipelining Protocols
Two generic forms of pipelined protocolsgo-Back-Nselective repeat
61
A Summary of Questions
How to improve the performance of rdt3.0? sliding window protocols
What if there are duplication and reordering? network guarantee: max packet life time transport guarantee: not reuse a seq# before
life time seq# management and connection
management How to determine the “right” parameters?