4-1
Lecture 04: Transport Layer
Transport layer protocols in the Internet: UDP: connectionless transport TCP: connection-oriented transport TCP congestion control
link
session
path
name
address
Provides end-to-end connectivity, but not necessarily good performance
Internet transport-layer protocols reliable, in-order delivery (TCP) congestion control flow control connection setup
unreliable, unordered delivery: UDP no-frills extension of “best-effort” IP
services not available: delay guarantees bandwidth guarantees
application
transport
networkdata link
physical
networkdata link
physical
networkdata link
physical
networkdata link
physical
networkdata link
physical
networkdata link
physical
networkdata link
physical
application
transport
networkdata link
physical
logical end-end transport
Two Basic Transport Features Demultiplexing: port numbers
Error detection: checksums
Web server(port 80)
Client host
Server host 128.2.194.242
Echo server(port 7)
Service request for128.2.194.242:80
(i.e., the Web server)OSClient
IP payload
detect corruption
User Datagram Protocol (UDP) Datagram messaging service
Demultiplexing: port numbers Detecting corruption: checksum
Lightweight communication between processes Send and receive messages Avoid overhead of ordered, reliable delivery
SRC port
DST port
checksum length
DATA
Advantages of UDP
Fine-grain control UDP sends as soon as the application writes
No connection set-up delay UDP sends without establishing a connection
No connection state No buffers, parameters, sequence #s, etc.
Small header overhead UDP header is only eight-bytes long
Popular Applications That Use UDP Multimedia streaming
Retransmitting packets is not always worthwhile
E.g., phone calls, video conferencing, gaming, IPTV
Simple query-response protocols Overhead of connection establishment is overkill
E.g., Domain Name System (DNS), DHCP, etc.
“Address for www.cnn.com?”
“12.3.4.15”
Transmission Control Protocol (TCP) Stream-of-bytes service Sends and receives a stream of bytes
Reliable, in-order delivery Corruption: checksums Detect loss/reordering: sequence numbers
Reliable delivery: acknowledgments and retransmissions
Connection oriented Explicit set-up and tear-down of TCP connection
Flow control Prevent overflow of the receiver’s buffer space
Congestion control Adapt to network congestion for the greater good
Breaking a Stream of Bytes into TCP Segments
TCP “Stream of Bytes” Service
By te 0
By te 1
By te 2
By te 3
By te 0
By te 1
By te 2
By te 3
Host A
Host B
By te 8 0
By te 8 0
…Emulated Using TCP “Segments”
By te 0
By te 1
By te 2
By te 3
By te 0
By te 1
By te 2
By te 3
Host A
Host B
By te 8 0
TCP Data
TCP Data
By te 8 0
Segment sent when:1. Segment full (Max Segment Size),2. Not full, but times out, or3. “Pushed” by application.
TCP Segment IP packet
No bigger than Maximum Transmission Unit (MTU)
E.g., up to 1500 bytes on an Ethernet link TCP packet
IP packet with a TCP header and data inside TCP header is typically 20 bytes long
TCP segment No more than Maximum Segment Size (MSS) bytes
E.g., up to 1460 consecutive bytes from the stream
IP HdrIP Data
TCP HdrTCP Data (segment)
Sequence NumberHost A
Host B
TCP Data
TCP Data
ISN (initial sequence number)
Sequence number = 1st
byte
By te 8 1
Reliable Delivery on a Lossy Channel With Bit Errors
Challenges of Reliable Data Transfer
Over a perfectly reliable channel Easy: sender sends, and receiver receives
Over a channel with bit errors Receiver detects errors and requests retransmission
Over a lossy channel with bit errors Some data are missing, and others corrupted Receiver cannot always detect loss
Over a channel that may reorder packets Receiver cannot distinguish loss from out-of-order
An Analogy
Alice and Bob are talking What if Bob couldn’t understand Alice? Bob asks Alice to repeat what she said
What if Bob hasn’t heard Alice for a while? Is Alice just being quiet? Has she lost reception?
How long should Bob just keep on talking? Maybe Alice should periodically say “uh huh”
… or Bob should ask “Can you hear me now?”
Take-Aways from the Example Acknowledgments from receiver
Positive: “okay” or “uh huh” or “ACK” Negative: “please repeat that” or “NACK”
Retransmission by the sender After not receiving an “ACK” After receiving a “NACK”
Timeout by the sender (“stop and wait”) Don’t wait forever without some acknowledgment
TCP Support for Reliable Delivery Detect bit errors: checksum
Used to detect corrupted data at the receiver …leading the receiver to drop the packet
Detect missing data: sequence number Used to detect a gap in the stream of bytes ... and for putting the data back in order
Recover from lost data: retransmission Sender retransmits lost or corrupted data Two main ways to detect lost packets
TCP AcknowledgmentsHost A
Host B
TCP Data
TCP Data
ISN (initial sequence number)
Sequence number = 1st byte
ACK sequence number = next expected byte
Automatic Repeat reQuest (ARQ)
ACK and timeouts Receiver sends ACK when it receives packet
Sender waits for ACK and times out
Simplest ARQ protocol Stop and wait Send a packet, stop and wait until ACK arrives
Time
Packet
ACKTim
eou
t
Sender Receiver
Flow Control:TCP Sliding Window
22
Motivation for Sliding Window Stop-and-wait is inefficient
Only one TCP segment is “in flight” at a time
Especially bad for high “delay-bandwidth product”
delay
bandwidth
Numerical Example 1.5 Mbps link with 45 msec round-trip time (RTT) Delay-bandwidth product is 67.5 Kbits (or 8 KBytes)
Sender can send at most one packet per RTT Assuming a segment size of 1 KB (8 Kbits) 8 Kbits/segment at 45 msec/segment 182 Kbps
That’s just one-eighth of the 1.5 Mbps link capacity
3-24
Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged packets range of sequence numbers must be increased buffering at sender and/or receiver
Pipelined protocols: concurrent logical channels, sliding window protocol
3-25
Sliding Window Protocol Consider an infinite array, Source, at the sender, and an infinite array, Sink, at the receiver.
0 1 2 a–1 a s–1 s
send window
acknowledged unacknowledged
0 1 2 r
received
delivered receive window
r + RW – 1
Source:
Sink:
P1Sender
P2Receiver
next expected
RW receive window sizeSW send window size (s - a SW)
3-26
Sliding Windows in Action Data unit r has just been received by P2
Receive window slides forward P2 sends cumulative ack with sequence number it expects to receive next (r+3)
unacknowledged
0 1 2 a–1 a s–1 s
send window
acknowledged
Source:
P1Sender
0 1 2 r
delivered receive window
r + RW – 1Sink:
P2Receiver
next expected
r+3
3-27
Sliding Windows in Action P1 has just received cumulative ack with r+3 as next expected sequence number Send window slides forward
0 1 2 a–1 a s–1 s
send window
acknowledged
0 1 2 r
delivered receive window
r + RW – 1
Source:
Sink:
P1Sender
P2Receiver
next expected
3-28
Sliding Window protocol Functions provided
error control (reliable delivery) in-order delivery flow and congestion control (by varying send window size)
TCP uses only cumulative acks Other kinds of acks
selective nack selective ack (TCP SACK) bit-vector representing entire state of receive window (in addition to first sequence number of window)
3-29
Sliding Window Protocol
At the sender, a will be pointed to by SendBase, and s by NextSeqNum
0 1 2 a–1 a s–1 s
send window
acknowledged unacknowledged
0 1 2 r
received
delivered receive window
r + RW – 1
Source:
Sink:
P1Sender
P2Receiver
next expected
RW receive window sizeSW send window size (s - a SW)
3-30
TCP Flow Controlreceiver: explicitly
informs sender of (dynamically changing) amount of free buffer space RcvWindow field in TCP segment
sender: keeps amount of transmitted, unACKed data less than most recently received RcvWindow value
sender won’t overrun
receiver’s buffers by
transmitting too much,
too fast
flow control
buffer at receive side of a TCP connection
Optimizing Retransmissions
Reasons for Retransmission
Packet
ACK
Tim
eou
t
Packet
ACK
Tim
eou
t
Packet
Tim
eou
t
Packet
ACK
Tim
eou
t
Packet
ACK
Tim
eou
tPacket
ACK
Tim
eou
t
ACK lostDUPLICATE
PACKET
Packet lost Early timeoutDUPLICATEPACKETS
How Long Should Sender Wait? Sender sets a timeout to wait for an ACK
Too short: wasted retransmissions Too long: excessive delays when packet lost
TCP sets timeout as a function of the RTT Expect ACK to arrive after an “round-trip time”
… plus a fudge factor to account for queuing But, how does the sender know the RTT?
Running average of delay to receive an ACK
TCP Round Trip Time and TimeoutQ: how to estimate RTT? SampleRTT: measured time from segment transmission until ACK receipt ignore retransmissions
SampleRTT will vary, want estimated RTT “smoother” average several recent measurements, not just current SampleRTT
TCP Round Trip Time and TimeoutEstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
Exponential weighted moving average influence of past sample decreases exponentially fast
typical value: = 0.125
Example RTT estimation:RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
RTT
(mill
isec
onds
)
SampleRTT Estimated RTT
3-37
TCP: retransmission scenarios
Host A
Seq=100, 20 bytes data
ACK=100
timepremature timeout scenario
Host B
Seq=92, 8 bytes data
ACK=120
Seq=92, 8 bytes data
Seq=92 timeout
ACK=120
Host A
Seq=92, 8 bytes data
ACK=100
losstimeout
lost ACK scenario
Host B
X
Seq=92, 8 bytes data
ACK=100
time
Seq=92 timeout
SendBase= 100
SendBase= 120
SendBase= 120
Sendbase= 100
3-38
TCP retransmission scenarios (more)
Host A
Seq=92, 8 bytes data
ACK=100
loss
timeout
Cumulative ACK scenario
Host B
X
Seq=100, 20 bytes data
ACK=120
time
SendBase= 120
Fast Retransmit
Time-out period often relatively long: long delay before resending lost packet
Detect lost segments via duplicate ACKs. Sender often sends many segments back-to-back
If segment is lost, there will likely be many duplicate ACKs.
If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: fast retransmit: resend segment before timer expires
Host A
timeout
Host B
time
X
resend 2nd segment
Figure 3.37 Resending a segment after triple duplicate ACK
3-41
event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there remains a not-yet-acknowledged segment) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y
reset timer for y }
Fast retransmit algorithm:
a duplicate ACK for already ACKed segment
fast retransmit
Effectiveness of Fast Retransmit
When does Fast Retransmit work best? High likelihood of many packets in flight Long data transfers, large window size, …
Implications for Web traffic Most Web transfers are short (e.g., 10 packets)•So, often there aren’t many packets in flight
Making fast retransmit is less likely to “kick in”•Forcing users to click “reload” more often…
Starting and Ending a Connection:TCP Handshakes
Establishing a TCP Connection
Three-way handshake to establish connection Host A sends a SYN (open) to the host B Host B returns a SYN acknowledgment (SYN ACK) Host A sends an ACK to acknowledge the SYN ACK
SYN
SYN ACK
ACKData
A B
Data
Each host tells its ISN to the other host.
What if the SYN Packet Gets Lost? Suppose the SYN packet gets lost
Packet is lost inside the network, or Server rejects the packet (e.g., listen queue is full)
Eventually, no SYN-ACK arrives Sender sets a timer and wait for the SYN-ACK … and retransmits the SYN if needed
How should the TCP sender set the timer? Sender has no idea how far away the receiver is
Some TCPs use a default of 3 or 6 seconds
SYN Loss and Web Downloads User clicks on a hypertext link
Browser creates a socket and does a “connect” The “connect” triggers the OS to transmit a SYN
If the SYN is lost… The 3-6 seconds of delay is very long The impatient user may click “reload”
User triggers an “abort” of the “connect” Browser “connects” on a new socket Essentially, forces a fast send of a new SYN!
Lecture 04: Transport Layer
Transport layer protocols in the Internet: UDP: connectionless transport TCP: connection-oriented transport TCP congestion control
Principles of Congestion Control
Congestion: informally: “too many sources sending too much data too fast for network to handle”
different from flow control! manifestations:
lost packets (buffer overflow at routers)
long delays (queueing in router buffers)
a top-10 problem!
Receiver Window vs. Congestion Window Flow control
Keep a fast sender from overwhelming a slow receiver
Congestion control Keep a set of senders from overloading the network
Different concepts, but similar mechanisms TCP flow control: receiver window TCP congestion control: congestion window Sender TCP window =
min { congestion window, receiver window }
How it Looks to the End Host Delay: Packet experiences high delay
Loss: Packet gets dropped along path
How does TCP sender learn this? Delay: Round-trip time estimate Loss: Timeout and/or duplicate acknowledgments✗
Congestion Collapse
Easily leads to congestion collapse Senders retransmit the lost packets Leading to even greater load … and even more packet loss
Load
Goodput “congestioncollapse”
Increase in load that results in a decrease in
useful work done.
Approaches towards congestion control
End-to-end congestion control:
no explicit feedback from network
congestion inferred from end-system’s observed loss and/or delay
approach taken by TCP
Network-assisted congestion control:
routers provide feedback to end systems single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM)
explicit sending rate for sender
TCP Congestion control
end-to-end control (no network assistance)
Tradeoff Pro: avoids needing explicit network feedback
Con: continually under- and over-shoots “right” rate
TCP Congestion control
Each TCP sender maintains a congestion windowMax number of bytes to have in transit (not yet ACK’d)
Adapting the congestion window Decrease upon losing a packet: backing off
Increase upon success: optimistically exploring
Always struggling to find right transfer rate
TCP Congestion Control
How does sender determine CongWin? loss event = timeout or 3 duplicate acks TCP sender reduces CongWin after loss event
three mechanisms: slow start AIMD reduce to 1 segment after timeout event
TCP Slow Start
Probing for usable bandwidth
When connection begins, CongWin = 1 MSS Example: MSS = 500 bytes & RTT = 200 msec initial rate = 20 kbps
available bandwidth may be >> MSS/RTT desirable to quickly ramp up to a higher rate
TCP Slow Start (more)
When connection begins, increase rate exponentially until first loss event or “threshold” double CongWin every RTT
done by incrementing CongWin by 1 MSS for every ACK received
Summary: initial rate is slow but ramps up exponentially fast
Host A
one segment
RTT
Host B
time
two segments
four segments
Congestion avoidance state & responses to loss eventsQ: If no loss, when
should the exponential increase switch to linear?
A: When CongWin gets to current value of threshold
Implementation: For initial slow start,
threshold is set to a very large value (e.g., 65 Kbytes)
At loss event, threshold is set to 1/2 of CongWin just before loss event
0
2
4
6
8
10
12
14
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Transmission round
con
ges
tio
n w
ind
ow
siz
e (s
egm
ents
)
Series1 Series2
threshold
TCP Tahoe
TCP
Reno
Rationale for Reno’s Fast Recovery
After 3 dup ACKs: CongWin is cut in half window then grows linearly
But after timeout event: CongWin is set to 1 MSS instead;
window then grows exponentially to a threshold, then grows linearly
3 dup ACKs indicates network capable of delivering some segments timeout occurring before 3 dup ACKs is “more alarming”
Summary: TCP Congestion Control When CongWin is below Threshold, sender in slow-start phase, window grows exponentially.
When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.
When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold.
When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.
AIMD in steady state
8 Kbytes
16 Kbytes
24 Kbytes
time
congestionwindow
multiplicative decrease: cut CongWin in half after loss event (3 dup acks)
additive increase: increase CongWin by 1 MSS every RTT in the absence of any loss event: probing
Long-lived TCP connection
Why is TCP fair?
Two competing sessions:
R
R
equal window size
Connection 1 window sizeConnection 2 window size
congestion avoidance: additive increase
loss: decrease window by factor of 2congestion avoidance: additive
increase
loss: decrease window by factor of 2
Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K (AIMD only provides convergence to same window size, not necessarily same throughput rate)
TCP connection 1
bottleneckrouter
capacity R
TCP connection 2
TCP Fairness
Fairness (more)
Fairness and UDP Multimedia apps often do not use TCP
do not want rate throttled by congestion control
Instead use UDP: pump audio/video at constant rate, tolerate packet loss
TCP-friendly congestion control for apps that prefer UDP, e.g., Datagram Congestion Control Protocol (DCCP)
End of Lecture04