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

2581

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

 one sender, one  bi-directional data flow
receiver in same connection
 reliable, in-order byte  MSS: maximum

steam: segment size

 no “message  connection-oriented:
boundaries”  handshaking (exchange
 pipelined: of control msgs) init’s
sender, receiver state
 TCP congestion and flow
before data exchange
control set window size
 flow controlled:
 send
application & receive buffers
w rites data
application
reads data
 sender will not
sock et sock et
door
TCP TCP
door overwhelm receiver
send buffer receive buffer
segm ent

3: Transport Layer 3b-1

 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 (not segments!)
U A Pnumber
head not
PSH: push data now len used
R S F rcvr window size
(generally not used) # bytes
checksum ptr urgent data
rcvr willing
RST, SYN, FIN: to accept
Options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)

3: Transport Layer 3b-2

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

3: Transport Layer 3b-3

TCP: reliable data transfer
event: data received
from application above simplified sender, assuming
create, send segment •one way data transfer
•no flow, congestion
control
event: timer timeout for
wait
wait
segment with seq # y
for
for
event
event retransmit segment

event: ACK received,

with ACK # y
ACK processing

3: Transport Layer 3b-4

TCP: 00 sendbase = initial_sequence number
01 nextseqnum = initial_sequence number
02

reliable 03 loop (forever) {

04
05
switch(event)
event: data received from application above

data 06
07
create TCP segment with sequence number nextseqnum
start timer for segment nextseqnum
08 pass segment to IP
transfer 09
10
nextseqnum = nextseqnum + length(data)
event: timer timeout for segment with sequence number y
11 retransmit segment with sequence number y
12 compue new timeout interval for segment y
Simplified 13 restart timer for sequence number y
14 event: ACK received, with ACK field value of y
TCP 15 if (y > sendbase) { /* cumulative ACK of all data up to y */
sender 16 cancel all timers for segments with sequence numbers < y
17 sendbase = y
18 }
19 else { /* a duplicate ACK for already ACKed segment */
20 increment number of duplicate ACKs received for y
21 if (number of duplicate ACKS received for y == 3) {
22 /* TCP fast retransmit */
23 resend segment with sequence number y
24 restart timer for segment y
25 }
26 } /* end of loop forever */
3: Transport Layer 3b-5
TCP ACK generation [RFC 1122, RFC
2581]

Event TCP Receiver action

in-order segment arrival, delayed ACK. Wait up to 500ms
no gaps, for next segment. If no next segment,
everything else already ACKed send ACK

in-order segment arrival, immediately send single

no gaps, cumulative ACK
one delayed ACK pending

out-of-order segment arrival send duplicate ACK, indicating seq. #

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

arrival of segment that immediate ACK if segment starts

partially or completely fills gap at lower end of gap

3: Transport Layer 3b-6

 TCP: retransmission scenarios
Host A Host B Host A Host B

Seq=9 Seq=9
2, 8 b 2, 8 b
y t es d y t es d
at a

Seq=92 timeout
at a Seq=
100,
20 b y
t es d

Seq=100 timeout
timeout

ata
100
A CK=
0
10
X CK
A AC
=
K =120
loss
Seq=9 Seq=9
2, 8 b 2, 8 b
y t es d y t es d
at a at a

=1 20
K
=10 0 AC
ACK

time time
lost ACK scenario premature timeout,
cumulative ACKs

3: Transport Layer 3b-7

 TCP Flow Control
flow control receiver: explicitly
sender won’t informs sender of
overrun (dynamically
receiver’s buffers by changing) amount of
transmitting too free buffer space
much,  RcvWindow field
RcvBuffer = size or too fast Buffer
TCP Receive in TCP segment
RcvWindow = amount of spare room in Buffer sender: keeps the
amount of
transmitted, unACKed
data less than most
recently received
RcvWindow

receiver buffering
3: Transport Layer 3b-8
TCP Round Trip Time and
Timeout
Q: how to set TCP Q: how to estimate RTT?
timeout value?  SampleRTT: measured time
 longer than RTT from segment transmission
until ACK receipt
 note: RTT will vary
 ignore retransmissions,
 too short: premature
cumulatively ACKed
timeout
segments
 unnecessary
 SampleRTT will vary, want
retransmissions
estimated RTT “smoother”
 too long: slow
 use several recent
reaction to segment
measurements, not just
loss
current SampleRTT

3: Transport Layer 3b-9

TCP Round Trip Time and
Timeout
EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT
 Exponential weighted moving average
 influence of given sample decreases exponentially
fast
 typical value of x: 0.1
Setting the timeout
 EstimtedRTT plus “safety margin”
 large variation in EstimatedRTT -> larger safety margin

Timeout = EstimatedRTT + 4*Deviation

Deviation = (1-x)*Deviation +
x*|SampleRTT-EstimatedRTT|

3: Transport Layer 3b-10

TCP Connection Management

Recall: TCP sender, receiver Three way

establish “connection”
before exchanging data
handshake:
segments
 initialize TCP variables:
Step 1: client end system
sends TCP SYN control
 seq. #s
segment to server
 buffers, flow control info
 specifies initial seq #
(e.g. RcvWindow)
 client: connection initiator Step 2: server end system
Socket clientSocket = new receives SYN, replies with
Socket("hostname","port
SYNACK control segment
number");
 server: contacted by client
 ACKs received SYN
Socket connectionSocket =  allocates buffers
welcomeSocket.accept();  specifies server->
receiver initial seq. #
3: Transport Layer 3b-11
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

3: Transport Layer 3b-12

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

timed wait
ACK
modification, can handly
simultaneous FINs. closed

closed

3: Transport Layer 3b-13

TCP Connection Management
(cont)

TCP server
lifecycle

TCP client
lifecycle

3: Transport Layer 3b-14

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!

3: Transport Layer 3b-15

 Causes/costs of congestion: scenario
1
 two senders, two
receivers
 one router,
infinite buffers
 no
retransmission

 large delays
when congested
 maximum
achievable
throughput

3: Transport Layer 3b-16

 Causes/costs of congestion: scenario
2
 one router, finite buffers
 sender retransmission of lost packet

3: Transport Layer 3b-17

Causes/costs of congestion: scenario
2
 always:  =  (goodput)
in out
 > out
 “perfect” retransmission only when loss:
in

 retransmission of delayed (not lost) packet makes
in

larger (than perfect case) for same
out

“costs” of congestion:
 more work (retrans) for given “goodput”
 unneeded retransmissions: link carries multiple copies of
pkt 3: Transport Layer 3b-18
Causes/costs of congestion: scenario
3
 four senders

Q: what happens as
 multihop paths in

and
 timeout/retransmit in
increase ?

3: Transport Layer 3b-19

Causes/costs of congestion: scenario
3

Another “cost” of congestion:

 when packet dropped, any “upstream
transmission capacity used for that packet was
wasted!
3: Transport Layer 3b-20
Approaches towards congestion
control
Two broad approaches towards congestion
control:
End-end congestion Network-assisted
control: congestion control:
 no explicit feedback from  routers provide feedback
network to end systems
 congestion inferred from  single bit indicating
end-system observed congestion (SNA,
loss, delay DECbit, TCP/IP ECN,
 approach taken by TCP ATM)
 explicit rate sender
should send at

3: Transport Layer 3b-21

Case study: ATM ABR congestion
control
ABR: available bit RM (resource
rate: management) cells:
 “elastic service”  sent by sender, interspersed
 if sender’s path with data cells
 bits in RM cell set by switches
“underloaded”:
 sender should use (“network-assisted”)
 NI bit: no increase in rate
available bandwidth
 if sender’s path
(mild congestion)
 CI bit: congestion
congested:
indication
 sender throttled to
 RM cells returned to sender
minimum
by receiver, with bits intact
guaranteed rate

3: Transport Layer 3b-22

Case study: ATM ABR congestion
control

 two-byte ER (explicit rate) field in RM cell

 congested switch may lower ER value in cell
 sender’ send rate thus minimum supportable rate on path

 EFCI bit in data cells: set to 1 in congested switch

 if data cell preceding RM cell has EFCI set, sender sets CI bit
in returned RM cell

3: Transport Layer 3b-23

TCP Congestion Control
 end-end control (no network assistance)
 transmission rate limited by congestion window size, Congwin,
over segments:

Congwin

 w segments, each with MSS bytes sent in one

RTT:
w * MSS
throughput = Bytes/sec
RTT

3: Transport Layer 3b-24

TCP congestion control:
 “probing” for usable  two “phases”
bandwidth:  slow start
 ideally: transmit as  congestion avoidance
fast as possible  important variables:
(Congwin as large as
 Congwin
possible) without loss
 increase Congwin until
 threshold: defines
loss (congestion) threshold between
two slow start phase,
 loss: decrease
congestion control
Congwin, then begin
phase
probing (increasing)
again

3: Transport Layer 3b-25

TCP Slowstart
Host A Host B
Slowstart algorithm one s e gm
ent

RTT
initialize: Congwin = 1
for (each segment ACKed) two segm
en ts
Congwin++
until (loss event OR
four segm
CongWin > threshold) ents

 exponential increase (per RTT)

in window size (not so slow!)
 loss event: timeout (Tahoe time
TCP) and/or or three duplicate
ACKs (Reno TCP)

3: Transport Layer 3b-26

 TCP Congestion Avoidance
Congestion avoidance
/* slowstart is over */
/* Congwin > threshold */
Until (loss event) {
every w segments ACKed:
Congwin++
}
threshold = Congwin/2
Congwin = 1
1
perform slowstart

1: TCP Reno skips slowstart (fast

recovery) after three duplicate ACKs
3: Transport Layer 3b-27
AIMD
TCP Fairness
TCP congestion
avoidance: Fairness goal: if N TCP
 AIMD: additive sessions share same
increase, bottleneck link, each
multiplicative should get 1/N of link
decrease capacity
 increase window by TCP connection 1
1 per RTT
 decrease window
by factor of 2 on
loss event
bottleneck
TCP
router
connection 2
capacity R

3: Transport Layer 3b-28

Why is TCP fair?
Two competing sessions:
 Additive increase gives slope of 1, as throughout increases
 multiplicative decrease decreases throughput proportionally

R equal bandwidth share

Connection 2 throughput

loss: decrease window by factor of 2

congestion avoidance: additive increase
loss: decrease window by factor of 2
congestion avoidance: additive increase

Connection 1 throughput R

3: Transport Layer 3b-29

 TCP latency modeling
Q: How long does it take Notation, assumptions:
to receive an object  Assume one link between
from a Web server after client and server of rate
sending a request? R
 TCP connection  Assume: fixed congestion
establishment window, W segments
 data transfer delay  S: MSS (bits)
 O: object size (bits)
 no retransmissions (no
Two cases to consider:loss, no corruption)
 WS/R > RTT + S/R: ACK for first segment in
window returns before window’s worth of
data sent
 WS/R < RTT + S/R: wait for ACK after sending
window’s worth of data sent 3: Transport Layer 3b-30
 TCP latency Modeling K:= O/WS

Case 1: latency = 2RTT + O/R Case 2: latency = 2RTT + O/R

+ (K-1)[S/R + RTT - WS/R]

3: Transport Layer 3b-31

 TCP Latency Modeling: Slow Start
 Now suppose window grows according to slow start.
 Will show that the latency of one object of size O is:

O  S S
Latency 2 RTT   P  RTT    ( 2 P  1)
R  R R

where P is the number of times TCP stalls at server:

P min{Q, K  1}

- where Q is the number of times the server would stall

if the object were of infinite size.

- and K is the number of windows that cover the object.

3: Transport Layer 3b-32

 TCP Latency Modeling: Slow Start (cont.)
initiate TC P
connection
Example:
request
O/S = 15 segments object
first w indow
= S /R

K = 4 windows R TT
second w indow
= 2S /R
Q=2
third w indow
= 4S /R
P = min{K-1,Q} = 2

Server stalls P=2 times.

fourth w indow
= 8S /R

com plete
object transm ission
delivered
tim e at
tim e at server
client

3: Transport Layer 3b-33

 TCP Latency Modeling: Slow Start (cont.)
S
 RTT time from when server starts to send segment
R
until server receives acknowledgement
initiate TC P
connection

S
2k  1 time to transmit the kth window request
R object
first w indow
= S /R


S k 1 S 
R TT
second w indow

 R  RTT  2 stall time after the kth window = 2S /R

R 
third w indow
= 4S /R

P
O
latency   2 RTT   stallTime p
fourth w indow
= 8S /R
R p 1
P
O S S
  2 RTT   [  RTT  2k  1 ]
R k 1 R R object
com plete
transm ission
delivered
O S S
  2 RTT  P[ RTT  ]  ( 2 P  1) tim e at
tim e at
server
R R R client

3: Transport Layer 3b-34

Chapter 3: Summary
 principles behind
transport layer services:
 multiplexing/ Next:
demultiplexing  leaving the network
 reliable data transfer “edge” (application
 flow control transport layer)
 congestion control  into the network
 instantiation and “core”
implementation in the
Internet
 UDP
 TCP

3: Transport Layer 3b-35