Internet Protocols
Fall 2005
Lecture 14
Transport Protocols-TCP
Andreas Terzis
Outline
– TCP Connection Management
– Sliding Window
– ACK Strategy
– Nagle’s algorithm
– Timeout estimation
– Flow Control
CS 349/Fall05
2
TCP Connection Management
TCP server
lifecycle
TCP client
lifecycle
wait 2 min
CS 349/Fall05
3
A
I-finished(M)
TCP state-transition diagram
B
FIN(M)
CLOSED
timer
on FIN
Wait
for B
to
finish
ACK (M+1)
may send
more data
Passive open
Active open/SYN
Close
Close
LISTEN
FIN (N)
I-finished
ack(N+1) ACK(N+1)
Done,
wait for 2MSL
delete
before deleting
state
the conn state
SYN_RCVD
Send/SYN
SYN/SYN + ACK
SYN/SYN + ACK
ACK
Close/FIN
SYN + ACK/ACK
ESTABLISHED
Close/FIN
FIN/ACK
FIN_WAIT_1
ACK
FIN_WAIT_2
SYN_SENT
CLOSE_WAIT
AC FIN/ACK
K
+
FI
N
/A
C
K
FIN/ACK
CS 349/Fall05
Close/FIN
CLOSING
LAST_ACK
ACK Timeout after two
segment lifetimes
TIME_WAIT
ACK
CLOSED
4
Connection Reset
• RST Segments
– When connection request arrives to nonexisting server, OS sends back RST signal
– Can be used to do abortive release of
established connection
• Receiver throws away queued data
CS 349/Fall05
5
Sliding Window Revisited
Sending application
Receiving application
TCP
TCP
LastByteWritten
LastByteAcked
• Sending side
LastByteRead
LastByteSent
(a)
– LastByteAcked < =
LastByteSent
– LastByteSent < =
LastByteWritten
– buffer bytes between
LastByteAcked and
LastByteWritten
NextByteExpected
LastByteRcvd
(b)
• Receiving side
– LastByteRead <
NextByteExpected
– NextByteExpected < =
LastByteRcvd +1
– buffer bytes between
NextByteRead and
LastByteRcvd
CS 349/Fall05
6
Protection Against Wrap Around
• 32-bit SequenceNum
Bandwidth
T1 (1.5 Mbps)
Ethernet (10 Mbps)
T3 (45 Mbps)
FDDI (100 Mbps)
STS-3 (155 Mbps)
STS-12 (622 Mbps)
STS-24 (1.2 Gbps)
Time Until Wrap Around
6.4 hours
57 minutes
13 minutes
6 minutes
4 minutes
55 seconds
28 seconds
CS 349/Fall05
7
Keeping the Pipe Full
• 16-bit AdvertisedWindow
Bandwidth
T1 (1.5 Mbps)
Ethernet (10 Mbps)
T3 (45 Mbps)
FDDI (100 Mbps)
STS-3 (155 Mbps)
STS-12 (622 Mbps)
STS-24 (1.2 Gbps)
Delay x Bandwidth Product
18KB
122KB
549KB
1.2MB
1.8MB
7.4MB
14.8MB
assuming 100ms RTT
CS 349/Fall05
8
Silly Window Syndrome
• How aggressively does sender exploit open
window?
Sender
Receiver
• Receiver-side solutions
– after advertising zero window, wait for space equal
to a maximum segment size (MSS)
– delayed acknowledgements
CS 349/Fall05
9
TCP Recvr: when to send ACK?
Event
TCP Receiver action
in-order segment arrival, no gaps,
everything earlier already ACKed
delayed ACK: wait up to 200ms,
If nothing arrived, send ACK
in-order segment arrival, no gaps,
one delayed ACK pending
immediately send one cumulative
ACK
out-of-order arrival: higher-than-expect
seq. #, gap detected
send duplicate ACK, indicating
seq. # of next expected byte
arrival of segment that partially or
completely fills a gap
immediate ACK if segment starts
at the lower end of gap
CS 349/Fall05
10
Nagle’s Algorithm
• How long does sender delay sending data?
– too long: hurts interactive applications
– too short: poor network utilization
– strategies: timer-based vs self-clocking
• When application generates additional data
– if fills a max segment (and window open): send it
– else
• if there is unack’ed data in transit: buffer it until ACK
arrives
• else: send it
CS 349/Fall05
11
TCP Flow Control
• receive side of TCP
connection has a receive
buffer:
flow control
sender won’t overflow
receiver’s buffer by
transmitting too much,
too fast
• app process may be
slow at reading from
buffer
CS 349/Fall05
• speed-matching
service: matching
the send rate to the
receiving app’s drain
rate
12
TCP Flow control: how it works
• Rcvr advertises spare room
by including value of
RcvWindow in segments
• Sender limits unACKed data
to RcvWindow
– guarantees receive buffer
doesn’t overflow
(Suppose TCP receiver
discards out-of-order
segments)
• spare room in buffer
= RcvWindow
= RcvBuffer-[LastByteRcvd LastByteRead]
CS 349/Fall05
13
Flow Control (cont.)
• If the receiver indicated size of zero in
last ACK how can the server send more
data?
– Sender periodically sends probes
– Receiver sends window update ACK
CS 349/Fall05
14
Setting Timers
• The sender needs to set retransmission
timers in order to know when to retransmit a
packet the may have been lost
• How long to set the timer for?
– Too short: may retransmit before data or ACK has
arrived, creating duplicates
– Too long: if a packet is lost, will take a long time
to recover (inefficient)
CS 349/Fall05
15
Timing Illustration
1
1
Timeout
RTT
RTT
1
Timeout
1
Timeout too long Æ
inefficiency
CS 349/Fall05
Timeout too short Æ
16
duplicate packets
Adaptive Timers
• The amount of time the sender should wait is about
the round-trip time (RTT) between the sender and
receiver
– For link-layer networks (LANs), this value is essentially
known
– For multi-hop WANS, rarely known
• Must work in both environments, so protocol should
adapt to the path behavior
• Measure successive ack delays T(n)
Set timeout = average + 4 deviations
CS 349/Fall05
17
RTT measurement and RTO
B
A
SRTT = (1-α) x SRTT + α x SampleRTT
rttvar = rttvar + β x (|diff| - rttvar)
Where diff = SampleRTT - SRTT
580ms
Assume SRTT = 500msec, rttvar = 120, α = 1/8, β = 1/4:
diff = SampleRTT - SRTT = 80ms
SRTT = SRTT + α x diff = 510ms
rttvar = rttvar + β (|diff| – rttvar) = 110
RTO = SRTT + 4 x rttvar = 510 + 440 = 950
600ms
CS 349/Fall05
18
How to measure RTT in case of
retransmission?
Host A
Host B
Host A
Retransmission
Host B
Retransmission
Wrong RTT
Sample
• Karn’s algorithm
– On retx, don’t update estimated RTT (and double RTO)
CS 349/Fall05
19
3-Way Handshaking (cont’d)
• Three-way handshake adds 1 RTT delay
• Why?
– Congestion control: SYN (40 byte) acts as
cheap probe
– Protects against delayed packets from
other connection (would confuse receiver)
CS 349/Fall05
20
Close Connection (Two-Army
Problem)
• Goal: both sides agree to close the connection
• Two-army problem:
– “Two blue armies need to simultaneously attack the white army to win; otherwise they
will be defeated. The blue army can communicate only across the area controlled by
the white army which can intercept the messengers.”
• What is the solution?
CS 349/Fall05
21
Close Connection
• 4-ways tear down connection
Host 1
Host 2
FIN
close
FIN ACK
FIN
close
ƒ Avoid reincarnation
ƒ Can retransmit FIN ACK
if it is lost
timeout
FIN ACK
closed
CS 349/Fall05
22