1

TCP

Many diagrams & slides are adapted from those by J.F Kurose and K.W. Ross
Many TCP flow diagrams from Stevens’ “TCP/IP Illustrated Vol. 1” 1st ed.
 2
Last Lecture
•Apps can send individual packets w/UDP; delivery is not guaranteed.
• Adds a port number and checksum to packets.
But most apps want reliable, stream-oriented transport (eg., TCP):
•Delivery confirmation & ordering is possible by sending ACKs
• After a timeout, resend packet that was not ACK’ed.
•Pipelining packets allow much better use of link capacity.
• Parallelizes ACK’ed communication
• Window size determines the number of allowed in-flight packets
•Go Back N is a simple pipelining protocol that uses cumulative ACKs.
•Selective Repeat adds buffering to the receiver to avoid unnecessary
repetition.
 3
TCP is practical reliable transport
•Has evolved from 1970s through today.
•Uses positive ACKS. Combines ideas from go-back-N and selective repeat.
•Also manages connection pacing (flow & congestion control)
•Unlike UDP, TCP requires that two hosts setup a connection before
exchanging data. Why?
• Exchange initial sequence numbers for both directions of the connection.
•Choose a random initial sequence number for two reasons:
• So new packets are not confused with retransmission from prior connection.
• So an attacker cannot easily inject fake packets in the data stream.
 4
TCP packet structure 32 bits
URG: urgent data counting by bytes
source port # dest port # of data
(generally not used)
sequence number (not segments!)
ACK: ACK # is valid acknowledgement number
head not
U A P R S F receive window
PSH: push data now len used
(generally not used) checksum urgent data ptr # bytes receiver is
willing to accept
RST, SYN, FIN: options (variable length)
connection establishment
(setup, teardown commands) Any TCP packet can
application data carry an ACK number,
(variable length, so ACKs can be “piggy
checksum as indicated in backed” on data
(as in UDP) flowing in the opposite
IP header)
direction.
 outgoing segment from sender 5
TCP seq #s and ACKs source port # dest port #
sequence number
acknowledgement number
•Sequence Numbers: rwnd
checksum urg pointer
• Indicate the offset in the byte stream of app data …
the segment’s first byte
window size
•Cumulative ACKs: N

• Send next expected sequence number sender sequence number space

(like Go Back N)
sent, sent, not-yet usable, not
•Receiver may drop out-of-order ACKed ACKed but not usable
(“in-flight”) yet sent
segments (like GBN), or buffer them
for later reassembly (like Selective incoming segment to sender

Repeat). source port # dest port #

sequence number
acknowledgement number
A rwnd
checksum urg pointer
 Seq = index of 6
Simple TCP example (after the handshake) data being sent.
ACK = index of
Web Browser Web Server data it expects to
Seqinit=42 Seqinit=79 receive next

Visits page, sending

100-byte long HTTP Seq=42, ACK=79, data = ‘GET /index.htm
request HTTP/1.1\r\nHost:…’
Server ACKs request, and sends
back 1200 bytes of HTML
Seq=79, ACK=142, data = ‘HTTP/1.1 200 OK…’

Client ACKs HTML body.

Does not have any other Seq=142, ACK=1279, data = ‘’
data to send. Server has already ACK’ed
142+0, so don’t send an ACK.
 7
Timeouts are an important parameter
•TCP keeps one timer, for oldest un-ACK’ed segment STOP
and
THINK
• Retransmit that one segment when timer expires. Why just one?
• ACK received → start timer for next-lowest un-ACK’ed segment, if any.
•Timer must be set carefully:
• Too long → waste time waiting before a necessary retransmit.
• Too short → send duplicate packets unnecessarily.
•What is the ideal value of the timer?
• In other words, how much time do we expect to elapse before getting ACK?
• Answer: just slightly longer than expected round-trip time (RTT). STOP
and
•Thus, TCP keeps track of recent RTTs by constantly measuring THINK

delay between every transmission and its ACK.

 8
Exponentially-weighted moving average RTT
EstimatedRTT = (1-α)*EstimatedRTT + α*SampleRTT
• Every time a new SampleRTT is observed, update the EWMA RTT.
• Typically, α = 0.125
•Gives us a “smoothed”
RTT: gaia.cs.umass.edu to
average of recent RTT. fantasia.eurecom.fr

•Then set

(milliseconds)
timeout > EstimatedRTT
•But how much greater? RTT
STOP
sampleRTT
and EstimatedRTT
THINK

time (seconds)
 9
RTT variance (jitter) also affects timeout choice
•Square points show
traffic with high variance
in RTT (high jitter)
• Should choose
timer significantly >
EstimatedRTT
•Circle points show
traffic with low variance
in RTT (low jitter)
• Can choose timer just
slightly > EstimatedRTT
 10
Final RTT estimation
•Also track an exponentially-weighted moving average of RTT deviation
(jitter):
DevRTT = (1-β)*DevRTT + β*|SampleRTT-EstimatedRTT|
Typically β=0.25

•Add a multiple of DevRTT as a “safety margin” above EstimatedRTT:

TimeoutInterval = EstimatedRTT + 4*DevRTT

• Initially set Timeout to one second, until we have some measurements.

 Timeout 11
initially set to High RTT, Moving average
one second high jitter makes the
High RTT, TimeoutInterval
low jitter adaptive to
changing
network
conditions

Low RTT period

 STOP 12
TCP retransmission scenarios and
THINK What if the second ACK is
dropped instead of the first?

SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data Seq=92, 8 bytes of data

Seq=100, 20 bytes of data Seq=100, 20 bytes of data

timeo

timeo
ACK=100
ACK=100
X
ut

ut

timeo
ACK=100 X

ut
ACK=120 ACK=120

Seq=92, 8 bytes of data Seq=92, 8

SendBase=100 bytes of data
Seq=120, 15 bytes of data
SendBase=120
ACK=100
ACK=120

SendBase=120

Lost ACK Premature timeout Lost ACK, but cumulative ACK

prevents retransmission
 13
Delayed ACKs
• TCP recommends that receiver wait before sending an ACK (RFC 1122).
• This allows the TCP’s ACK response (and receive window update) to be
piggy-backed on an application-layer response.
• Send ACK only after 500ms or with next data in other direction.
• Eg., an “echo” app that repeats back the data received:
Eager ACKs With delayed ACKs

processing delayed
time ACK

delayed
ACK
 14
TCP ACK generation (RFC 1122, 2581)
Event at Receiver TCP action taken
• Arrival of in-order segment with Delayed ACK. Wait up to 500ms for
expected seq #. All data up to next segment. If no next segment,
expected seq # already ACK’ed. send ACK.
• Arrival of in-order segment with Immediately send a single
expected seq #. One other segment cumulative ACK, ACK’ing both
has ACK pending. in-order segments.
• Arrival of out-of-order segment Immediately send duplicate ACK,
(with higher-than-expect seq #). indicating seq. # of next expected
In other words, a gap was detected. byte.
• Arrival of segment that partially or Immediately send ACK if segment
completely fills gap. starts at beginning of gap.
 15
TCP fast retransmit
•With using cumulative ACKs,
duplicate ACKs suggest packet loss. Seq=92, 8 bytes of data

• Receiver will always set ACK # to the Seq=100, 20 bytes of data

index of the next byte expected (the gap). X

•On triple duplicate ACK, instead of the
ACK=100
sender waiting for timer to expire, TCP ACK=100

timeout
fast retransmit immediately re-sends ACK=100
lowest un-ACK’ed segment. ACK=100

Seq=100, 20 bytes of data

fast retransmit after sender

receipt of triple duplicate ACK
 16
Triple DUP ACK
•Why does TCP wait for three duplicate ACKS before performing a
fast retransmit? Why not after one? STOP
and
THINK
•RFC 2001:
“Since TCP does not know whether a duplicate ACK is caused by a
lost segment or just a reordering of segments, it waits for a small
number of duplicate ACKs to be received. It is assumed that if there
is just a reordering of the segments, there will be only one or two
duplicate ACKs before the reordered segment is processed, which
will then generate a new ACK. If three or more duplicate ACKs are
received in a row, it is a strong indication that a segment has been
lost.”
 17
TCP has characteristics of both GBN and SR:
Go Back N Selective Repeat
•Only one timer is kept, but → •Re-send just one segment on timeout.
•Send cumulative ACKs, but → •Receiver may save out-of-order
•Duplicate ACK for early segment. segments for later reassembly.

Plus some new features:

•Guidelines for setting timeout interval, based on observations
•Delayed ACKs. • Triple duplicate ACK triggers a retransmit.
•Connection setup with 3-way handshake, and teardown.
•Window size changes to implement flow & congestion control
 18
TCP window → flow and congestion control
•Recall that window size limits the
maximum # of in-flight segments.
•Peak throughput is proportional to
window size (divided by RTT).
Sender Receiver
• Hosts control windows, not RTT.
•Control sender’s window size to
prevent packet loss, by preventing:
• Overflow of receiver’s receive buffer
# segments ≤ N (flow control).
• Overflow of routers’ packet queues
(congestion control).
 19
TCP flow control – to avoid overwhelming the receiver
32 bits •In receive window, host tells how
many bytes of new data it can receive.
source port # dest port #
sequence number •Sender simply tracks # un-ACK’ed
acknowledgement number
bytes and keeps this ≤ receive window.
head not
U A P R S F receive window • A simple and effective solution is
len used
possible because we can directly observe
checksum urgent data ptr
the receive buffer and report its status.
options (variable length) •Congestion control requires a more
complex solution because it involves
application data many routers along the path, and many
flows (connections) across each router.
• We must infer network congestion.
 20
TCP connection setup
•Before starting data exchange, hosts must agree on a few parameters:
• Initial sequence numbers (in both direction)
• Receive window size (for flow control)
•Recall: choose a random initial sequence number for two reasons:
• So new packets are not confused with retransmission from prior connection.
• So an attacker cannot easily inject fake packets in the data stream.
•Three-way handshake sets up the connection
1. SYN: Initiator sends its parameters (init. seq #, window size, etc.).
2. SYN-ACK: Listener sends ACK including its own parameters.
3. ACK: Initiator ACKs (and may include first segment of data).
Above ACKs use initial sequence number + 1
 21
3-way handshake, from “TCP/IP Illustrated” reference book
An example: In general:
seq # : end of data (data size)

May open a TCP socket:

• Actively (we specify the connection partner, and a SYN is sent)
• Passively (just listen for a SYN from unknown host)
Usually call the active initiator the client, and the passive listener the server.
 22
TCP connection close
•Each side of the connection sends FIN to say it’s finished sending.
• Waits for an ACK.
• Connection may be half closed if only one side is done sending.
23
 24
Protocol must also handle unusual timings
 25
TCP state transition diagram
 26
Recap
•TCP implements a combination of Go Back N and Selective Repeat.
•ACK timeout can be appropriately set with Exponentially-Weighted
Moving Average (EWMA) of recent RTT and recent jitter.
•ACKs count bytes, not packets, and can be piggybacked on data sent in
the reverse direction. ACKs are sometimes delayed for efficiency.
•Triple duplicate ACK suggests packet loss retransmit.
•Connection setup requires a 3-way handshake.
• Connection close also uses a handshake. Each direction is closed.
•TCP throughput should be regulated so as not to overwhelm:
• the receiver -- Flow control is implemented with explicit Receive Window.
• the network – Congestion control will be discussed next lecture.