1. Transmission Control Protocol (TCP)
CS 352, Lecture 8
Srinivas Narayana
(slides heavily adapted from text authors’ material)

2. Transmission Control Protocol: Overview
point-to-point:
one sender, one receiver
reliable, in-order byte stream:
no “message boundaries”
pipelined:
TCP congestion and flow control set window size
full duplex data:
bi-directional data flow in same connection
MSS: maximum segment size
connection-oriented:
handshaking (exchange of control msgs) inits sender, receiver state before data exchange
flow controlled:
sender will not overwhelm receiver
RFCs: 793,1122,1323, 2018, 2581

3. TCP segment structure source port # dest port # sequence number
32 bits
URG: urgent data
(generally not used)
counting
by bytes
of data
(not segments!)
source port #
dest port #
sequence number
ACK: ACK #
valid
acknowledgement number
head
len
not
used
PSH: push data now
(generally not used) U A P R S F
receive window
# bytes
rcvr willing
to accept
checksum
Urg data pointer
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
options (variable length)
application
data
(variable length)
Internet
checksum
(as in UDP)

4. TCP seq. numbers, ACKs sequence numbers:
source port #
dest port #
sequence number
acknowledgement number
checksum
rwnd
urg pointer
outgoing segment from sender
sequence numbers:
byte stream “number” of first byte in segment’s data
acknowledgements:
seq # of next byte expected from other side
cumulative ACK
How does receiver handle out-of-order segments?
A: TCP spec doesn’t say, up to implementor
window size N
sender sequence number space
source port #
dest port #
sequence number
acknowledgement number
checksum
rwnd
urg pointer
incoming segment to sender
sent
ACKed
sent, not-yet ACKed
(“in-flight”)
usable
but not
yet sent
not
usable A

5. simple telnet scenario
TCP seq. numbers, ACKs
Host A
Host B
User
types
‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
back ‘C’
Seq=79, ACK=43, data = ‘C’
host ACKs
receipt
of echoed
‘C’
Seq=43, ACK=80
simple telnet scenario

6. Reliable transfer in TCP

7. TCP reliable data transfer
TCP creates reliable service on top of IP’s unreliable service
pipelined segments
cumulative acks
single retransmission timer
retransmissions triggered by:
timeout events
duplicate acks
Let’s initially consider simplified TCP sender:
ignore duplicate acks
ignore flow control, congestion control

8. TCP round trip time, timeout
Q: how to set TCP timeout value?
longer than RTT
but RTT varies
too short: premature timeout, unnecessary retransmissions
too long: slow reaction to segment loss
Q: 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

9. TCP round trip time, timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
exponential weighted moving average
influence of past sample decreases exponentially fast
typical value:  = 0.125
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
RTT (milliseconds)
sampleRTT
EstimatedRTT
Transport Layer
time (seconds)

10. TCP round trip time, timeout
timeout interval: EstimatedRTT plus “safety margin”
large variation in EstimatedRTT -> larger safety margin
estimate SampleRTT deviation from EstimatedRTT:
DevRTT = (1-)*DevRTT +
* |SampleRTT-EstimatedRTT|
(typically,  = 0.25)
TimeoutInterval = EstimatedRTT + 4*DevRTT
estimated RTT
“safety margin”

11. TCP sender events: Managing a single timer
data rcvd from app:
create segment with seq #
seq # is byte-stream number of first data byte in segment
start timer if not already running
think of timer as for oldest unacked segment
expiration interval: TimeOutInterval
timeout:
retransmit segment that caused timeout
restart timer
ack rcvd:
if ack acknowledges previously unacked segments
update what is known to be ACKed
restart timer if there are still unacked segments

12. TCP: retransmission scenarios
Host A
Host B
Host A
Host B
SendBase=92
Seq=92, 8 bytes of data
Seq=92, 8 bytes of data
Seq=100, 20 bytes of data
timeout
timeout
ACK=100 X
ACK=100
ACK=120
Seq=92, 8 bytes of data
Seq=92, 8
bytes of data
SendBase=100
SendBase=120
ACK=100
ACK=120
SendBase=120
lost ACK scenario
Premature timeout
But segment 120 not transmitted

13. TCP: retransmission scenarios
Host A
Host B
timeout
Seq=92, 8 bytes of data
Seq=100, 20 bytes of data
ACK=100 X
ACK=120
Seq=120, 15 bytes of data
Cumulative ACK avoids retransmission altogether

14. TCP receiver events: ACKing [RFC 1122, RFC 2581]
event at receiver
arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
expected seq #. One other
segment has ACK pending
arrival of out-of-order segment
higher-than-expect seq. # .
Gap detected
arrival of segment that
partially or completely fills gap
TCP receiver action
delayed ACK. Wait up to 500ms
for next segment. If no next segment,
send ACK
immediately send single cumulative
ACK, ACKing both in-order segments
immediately send duplicate ACK,
indicating seq. # of next expected byte
immediate send ACK, provided that
segment starts at lower end of gap

15. TCP fast retransmit timeout period often relatively long:
long delay before resending lost packet
Instead: 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.
TCP fast retransmit
if sender receives 3 ACKs for same data
(“triple duplicate ACKs”),
resend unacked segment with smallest seq #
likely that unacked segment lost, so don’t wait for timeout

16. TCP fast retransmit X fast retransmit after sender
Host A
Host B
timeout
Seq=92, 8 bytes of data
Seq=100, 20 bytes of data X
ACK=100
ACK=100
ACK=100
ACK=100
Seq=100, 20 bytes of data
fast retransmit after sender
receipt of triple duplicate ACK

17. Problem with RTT Calculation
Sender
Receiver 2K
SEQ=0
Sender Timeout
RTT?
ACK = 2048 2K
SEQ=0
RTT?

18. Karn’s algorithm Retransmission ambiguity
Measure RTT from original data segment
Measure RTT from most recent segment
Either way there is a problem in RTT estimate
One solution
Never update RTT measurements based on acknowledgements from retransmitted packets
Problem: Sudden change in RTT can cause system never to update RTT
Primary path failure leads to a slower secondary path

19. Karn’s algorithm Use back-off as part of RTT computation
Whenever packet loss, RTO is increased by a factor
Use this increased RTO as RTO estimate for the next segment (not from SRTT)
Only after an acknowledgment received for a successful transmission is the timer set to new RTT obtained from SRTT

20. Flow Control

21. receiver protocol stack
TCP flow control
application
process
application may
remove data from
TCP socket buffers ….
application OS
TCP socket
receiver buffers
… slower than TCP
receiver is delivering
(sender is sending)
TCP
code IP
code
receiver controls sender, so sender won’t overflow receiver’s buffer by transmitting too much, too fast
flow control
from sender
receiver protocol stack

22. TCP flow control
receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to- sender segments
RcvBuffer size set via socket options (typical default is bytes)
many operating systems autoadjust RcvBuffer
sender limits amount of unacked (“in-flight”) data to receiver’s rwnd value
guarantees receive buffer will not overflow
to application process
buffered data
free buffer space
RcvBuffer
rwnd
TCP segment payloads
receiver-side buffering

23. Connection Management

24. Connection Management
before exchanging data, sender/receiver “handshake”:
agree to establish connection (each knowing the other willing to establish connection)
agree on connection parameters
application
application
connection state: ESTAB
connection variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client
connection state: ESTAB
connection Variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client
network
network
Socket clientSocket =
newSocket("hostname","port number");
Socket connectionSocket = welcomeSocket.accept();

25. Agreeing to establish a connection
2-way handshake:
Q: will 2-way handshake always work in network?
variable delays
retransmitted messages (e.g. req_conn(x)) due to message loss
message reordering
can’t “see” other side
Let’s talk
ESTAB OK
ESTAB
choose x
req_conn(x)
ESTAB
acc_conn(x)
ESTAB

26. Agreeing to establish a connection
2-way handshake failure scenarios:
choose x
req_conn(x)
ESTAB
acc_conn(x)
client terminates
ESTAB
choose x
req_conn(x)
acc_conn(x)
data(x+1)
accept
connection
x completes
server
forgets x
retransmit
req_conn(x)
ESTAB
half open connection!
(no client!)
retransmit
req_conn(x)
ESTAB
data(x+1)
accept
client terminates
server
forgets x
connection
x completes

27. TCP 3-way handshake client state server state LISTEN SYNSENT
SYNbit=1, Seq=x
choose init seq num, x
send TCP SYN msg
SYN RCVD
ESTAB
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
choose init seq num, y
send TCP SYNACK
msg, acking SYN
ACKbit=1, ACKnum=y+1
received SYNACK(x)
indicates server is live;
send ACK for SYNACK;
this segment may contain
client-to-server data
received ACK(y)
indicates client is live
ESTAB
Transport Layer

28. TCP 3-way handshake: FSM
closed
Socket connectionSocket = welcomeSocket.accept(); L
Socket clientSocket =
newSocket("hostname","port number");
SYN(x)
SYNACK(seq=y,ACKnum=x+1)
create new socket for
communication back to client
listen
SYN(seq=x)
SYN
rcvd
SYN
sent
SYNACK(seq=y,ACKnum=x+1)
ACK(ACKnum=y+1)
ACK(ACKnum=y+1)
ESTAB L

29. TCP: closing a connection
client, server each close their side of connection
send TCP segment with FIN bit = 1
respond to received FIN with ACK
on receiving FIN, ACK can be combined with own FIN
simultaneous FIN exchanges can be handled

30. TCP: closing a connection
client state
server state
ESTAB
ESTAB
FIN_WAIT_1
FINbit=1, seq=x
can no longer
send but can
receive data
clientSocket.close()
CLOSE_WAIT
FIN_WAIT_2
ACKbit=1; ACKnum=x+1
wait for server
close
can still
send data
can no longer
send data
LAST_ACK
TIMED_WAIT
FINbit=1, seq=y
CLOSED
timed wait
for 2*max
segment lifetime
CLOSED
ACKbit=1; ACKnum=y+1