TCP

Transport Layer 3-1

 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

 point-to-point:  full duplex data:

 one sender, one receiver  bi-directional data flow

 reliable, in-order byte in same connection

 MSS: maximum segment
steam:
size
 no “message boundaries”
 connection-oriented:
 pipelined:
 handshaking (exchange
 TCP congestion and flow
of control msgs) init’s
control set window size sender, receiver state
 send & receive buffers before data exchange
 flow controlled:
 sender will not
a p p lic a t io n a p p lic a t io n
w r ite s d a ta re a d s d a ta
socket socket

overwhelm receiver
door door
TC P TC P
s e n d b u ffe r r e c e iv e b u f f e r
segm ent

Transport Layer 3-2

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

Transport Layer 3-3

 TCP seq. #’s and ACKs
Seq. #’s:
Host A Host B
 byte stream “number”
of first byte in User Seq=4
2,
segment’s data types ACK=
79, da
t a = ‘C
ACKs: ‘C’ ’
host ACKs
 seq # of next byte receipt of
expected from other = ‘C’ ‘C’, echoes
43 , data
side 9 , ACK
= back ‘C’
=7
Seq
 cumulative ACK
 piggybacking host ACKs
Q: how receiver handles out- receipt Seq=4
of echoed 3, ACK
of-order segments =80
‘C’
 A: TCP spec doesn’t
say, - up to
implementor time
simple telnet scenario

Transport Layer 3-4

TCP Round Trip Time and Timeout
Q: how to set TCP Q: how to estimate RTT?
timeout value?  SampleRTT: measured time from
 longer than RTT segment transmission until ACK
 but RTT varies
receipt
 ignore retransmissions
 too short: premature
timeout  SampleRTT will vary, want
 unnecessary estimated RTT “smoother”
 average several recent
retransmissions
 too long: slow reaction measurements, not just
to segment loss current SampleRTT

Transport Layer 3-5

Example RTT estimation:
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

300

250
RTT (milliseconds)

200

150

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)

SampleRTT Estimated RTT

Transport Layer 3-6

TCP reliable data transfer
 TCP creates rdt  Retransmissions are
service on top of IP’s triggered by:
unreliable service  timeout events
 Pipelined segments  duplicate acks
 Cumulative acks  Initially consider
 TCP uses single simplified TCP sender:
ignore duplicate acks
retransmission timer

 ignore flow control,
congestion control

Transport Layer 3-7

TCP sender events:
data rcvd from app: timeout:
 Create segment with  retransmit segment
seq # that caused timeout
 seq # is byte-stream  restart timer
number of first data Ack rcvd:
byte in segment  If acknowledges
 start timer if not
previously unacked
already running (think segments
of timer as for oldest  update what is known to
unacked segment) be acked
 expiration interval:  start timer if there are
TimeOutInterval outstanding segments

Transport Layer 3-8

NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum

loop (forever) { TCP

sender
switch(event)

event: data received from application above

create TCP segment with sequence number NextSeqNum (simplified)
if (timer currently not running)
start timer
pass segment to IP
Comment:
NextSeqNum = NextSeqNum + length(data)
• SendBase-1: last
event: timer timeout cumulatively
retransmit not-yet-acknowledged segment with ack’ed byte
smallest sequence number Example:
start timer • SendBase-1 = 71;
y= 73, so the rcvr
event: ACK received, with ACK field value of y wants 73+ ;
if (y > SendBase) {
y > SendBase, so
SendBase = y
if (there are currently not-yet-acknowledged segments)
that new data is
start timer acked
}

} /* end of loop forever */

Transport Layer 3-9
 TCP: retransmission scenarios
Host A Host B Host A Host B

Seq=9 Seq=9
2, 8 b 2, 8 b y te
y te s d a s data
ta Seq=

Seq=92 timeout
1 00, 2
0 by t
es da
timeout

t a
=100
ACK 0
10
X CK=
A AC K = 120
loss
Seq=9 Seq=9
2, 8 b
2, 8 b
y t es da Sendbase y t es da
ta
ta
= 100

Seq=92 timeout
SendBase
= 120 = 120
0 K
=10 AC
ACK

SendBase
= 100 SendBase
= 120 premature timeout
time time
lost ACK scenario
Transport Layer 3-10
 TCP retransmission scenarios (more)
Host A Host B

Seq=9
2, 8 byte
s data

=100
timeout

Seq=1 A CK
00, 20
bytes
data
X
loss

SendBase C K =120
A
= 120

time
Cumulative ACK scenario

Transport Layer 3-11

TCP ACK generation [RFC 1122, RFC 2581]

Event at Receiver TCP Receiver action

Arrival of in-order segment with Delayed ACK. Wait up to 500ms
expected seq #. All data up to for next segment. If no next segment,
expected seq # already ACKed send ACK

Arrival of in-order segment with Immediately send single cumulative

expected seq #. One other ACK, ACKing both in-order segments
segment has ACK pending

Arrival of out-of-order segment Immediately send duplicate ACK,

higher-than-expect seq. # . indicating seq. # of next expected byte
Gap detected

Arrival of segment that Immediate send ACK, provided that

partially or completely fills gap segment startsat lower end of gap

Transport Layer 3-12

Fast Retransmit
 Time-out period often  If sender receives 3
relatively long: ACKs for the same
 long delay before data, it supposes that
resending lost packet segment after ACKed
 Detect lost segments data was lost:
via duplicate ACKs.  fast retransmit: resend
 Sender often sends segment before timer
many segments back-to- expires
back
 If segment is lost,
there will likely be many
duplicate ACKs.

Transport Layer 3-13

TCP Flow Control
flow control
sender won’t overflow
 receive side of TCP
receiver’s buffer by
connection has a transmitting too
receive buffer: much,
too fast

 speed-matching
service: matching the
send rate to the
receiving app’s drain
 app process may be
rate
slow at reading from
buffer
Transport Layer 3-14
TCP Flow control: how it works
 Rcvr advertises spare
room by including value
of RcvWindow in
segments
 Sender limits unACKed
(Suppose TCP receiver data to RcvWindow
discards out-of-order  guarantees receive
segments) buffer doesn’t overflow
 spare room in buffer
= RcvWindow
= RcvBuffer-[LastByteRcvd -
LastByteRead]

Transport Layer 3-15

TCP Connection Management

Recall: TCP sender, receiver establish “connection”

before exchanging data segments
 initialize TCP variables:
 seq. #s
 buffers, flow control info (e.g. RcvWindow)
 client: connection initiator
Socket clientSocket = new Socket("hostname","port
number");
 server: contacted by client
Socket connectionSocket = welcomeSocket.accept();

Transport Layer 3-16

TCP Connection Management

Three way handshake:

Step 1: client host sends TCP SYN segment to server
 specifies initial seq #
 no data

Step 2: server host receives SYN, replies with

SYNACK segment
 server allocates buffers
 specifies server initial seq. #

Step 3: client receives SYNACK, replies with ACK

segment, which may contain data
Transport Layer 3-17
TCP Connection Management (cont.)

Closing a connection: client server

client closes socket: close

FIN
clientSocket.close();

Step 1: client end system

ACK
sends TCP FIN control close
segment to server FIN

Step 2: server receives FIN,

timed wait
ACK
replies with ACK. Closes
connection, sends FIN.

closed

Transport Layer 3-18

TCP Connection Management (cont.)

Step 3: client receives FIN, client server

replies with ACK.
closing
FIN
 Enters “timed wait” - will
respond with ACK to
received FINs
ACK
closing
Step 4: server, receives ACK. FIN
Connection closed.

Note: with small modification,

timed wait
ACK
can handle simultaneous FINs.
closed

closed

Transport Layer 3-19