ECSE-4670: Computer TCP: Overview

Communication Networks (CCN)

• Point-to-point:
– one sender, one receiver
Chapter 3: TCP • Reliable, in-order byte steam:
Shivkumar Kalyanaraman: shivkuma@ecse.rpi.edu – no “message boundaries”
Biplab Sikdar: sikdab@rpi.edu – But TCP chops it up into segments for
transmission internally
• Pipelined (window) flow control:
– Window size decided by receiver and
network
• Send & receive buffers
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 1 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 2

TCP: Overview TCP: Overview

• Full duplex data:
– bi-directional data flow in same connection
application application
– MSS: maximum segment size
writes data
socket
door
reads data
socket • Connection-oriented:
door
TCP
send buffer
TCP
receive buffer
– handshaking (exchange of control msgs)
segment init’s sender, receiver state before data
exchange
• Flow & Congestion Control:
– sender will not overwhelm receiver or the
network

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 3 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 4

TCP segment structure TCP seq. #’s and ACKs (I)

32 bits
URG: urgent data counting Sequence Numbers:
(generally not used) source port # dest port #
by bytes – byte stream “number” of first byte in
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!) segment’s data
head not
PSH: push data now len used
UAP R S F rcvr window size
(generally not used) # bytes
checksum ptr urgent data
rcvr willing ACKs:
to accept
RST, SYN, FIN: Options (variable length) – seq # of next byte expected from other side
connection estab
(setup, teardown – cumulative ACK
commands)
application
Internet data
checksum (variable length) Q: how receiver handles out-of-order segments
(as in UDP) – A: TCP spec doesn’t say, - up to
implementor
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 5 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 6

1
 TCP Seq. #’s and ACKs (II) Temporal Redundancy Model
Host A Host B Packets • Sequence Numbers
User Seq=4
• CRC or Checksum
2, A
types CK=7
9, data
‘C’ = ‘C’ Timeout
host ACKs
receipt of Status Reports • ACKs
data
= ‘C’ ‘C’, echoes • NAKs,
3,
79, A CK=4 back ‘C’ • SACKs
Seq=
• Bitmaps
host ACKs
receipt Seq=4 Retransmissions
of echoed 3, A CK=8
‘C’
0 • Packets
• FEC information

simple telnet scenario

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 7 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 8

Status Report Design TCP: reliable data transfer (I)

• Cumulative acks:
event: data received
– Robust to losses on the reverse channel from application above
– Can work with go-back-N retransmission create, send segment • one way data transfer
– Cannot pinpoint blocks of data which are
lost wait event: timer timeout for • no flow, congestion
wait segment with seq # y
• The first lost packet can be pinpointed for
for control
event
event retransmit segment
because the receiver would generate
duplicate acks
event: ACK received,
with ACK # y
ACK processing
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 9 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 10

00 sendbase = initial_sequence number

01 nextseqnum = initial_sequence number
02 TCP ACK generation
03 loop (forever) {
04 switch(event)
05 event: data received from application above
06 create TCP segment with sequence number nextseqnum
TCP: 07
08
start timer for segment nextseqnum
pass segment to IP
Event TCP Receiver action
09 nextseqnum = nextseqnum + length(data)
reliable 10
11
12
event: timer timeout for segment with sequence number y
retransmit segment with sequence number y
compute new timeout interval for segment y
in-order segment arrival,
no gaps,
delayed ACK. Wait up to 500ms
for next segment. If no next segment,
data 13
14
15
restart timer for sequence number y
event: ACK received, with ACK field value of y
if (y > sendbase) { /* cumulative ACK of all data up to y */
everything else already ACKed send ACK

in-order segment arrival, immediately send single

transfer (II) 16
17
18
cancel all timers for segments with sequence numbers < y
sendbase = y
}
no gaps, cumulative ACK
19 else { /* a duplicate ACK for already ACKed segment */ one delayed ACK pending
20 increment number of duplicate ACKs received for y
21 if (number of duplicate ACKS received for y == 3) {
Simplified 22 /* TCP fast retransmit */ out-of-order segment arrival send duplicate ACK, indicating seq. #
23 resend segment with sequence number y higher-than-expect seq. # of next expected byte
TCP 24
25 }
restart timer for segment y
gap detected!
sender 26 } /* end of loop forever */
arrival of segment that immediate ACK if segment starts
partially or completely fills gap at lower end of gap
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 11 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 12

2
 TCP: retransmission scenarios TCP Flow Control
flow control receiver: explicitly
Host A Host B Host A Host B sender won’t overrun informs sender of
Seq=9 Seq=9 receiver’s buffers by free buffer space
2, 8 b 2, 8 b
ytes d ytes d
ata transmitting too much,
– RcvWindow

Seq=92 timeout
ata Seq=
100, too fast
20 by
tes d field in TCP

Seq=100 timeout
timeout

ata
=100
ACK 0 segment
10 RcvBuffer = size or TCP Receive Buffer
X K=
AC CK=1
20
loss A RcvWindow = amount of spare room in Buffer sender: keeps the
Seq=9
2, 8 b
Seq=9
2, 8 b
ytes d
amount of
ytes d ata
ata transmitted,
unACKed data less
20 than most recently
=100 K=1
ACK AC
received
RcvWindow
time time premature timeout,
lost ACK scenario
cumulative ACKs receiver buffering
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 13 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 14

Timeout and RTT Estimation How to estimate max RTT?

• Timeout: for robust detection of • RTT = prop + queuing delay
packet loss – Queuing delay highly variable
– So, different samples of RTTs will give
• Problem: How long should timeout different random values of queuing delay
be ?
– Too long => underutilization • Chebyshev’s Theorem:
– MaxRTT = Avg RTT + k*Deviation
– Too short => wasteful
– Error probability is less than 1/(k**2)
retransmissions
– Result true for ANY distribution of
– Solution: adaptive timeout: based on samples
estimate of max RTT
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 15 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 16

TCP Round Trip Time and

Round Trip Time and Timeout (II)
Timeout (III)
Q: how to estimate RTT?
AverageRTT = (1-x)*AverageRTT + x*SampleRTT
• SampleRTT: measured time from segment
• Exponential weighted moving average (EWMA)
transmission until ACK receipt
• influence of given sample decreases
– ignore retransmissions, cumulatively exponentially fast; x = 0.1
ACKed segments
Setting the timeout
• SampleRTT will vary wildly => want
• AverageRTT plus “safety margin” proportional to
estimated RTT “smoother”
variation
– use several recent measurements, not
Timeout = AverageRTT + 4*Deviation
just current SampleRTT to calculate
Deviation = (1-x)*Deviation + x*|SampleRTT- AverageRTT|
“AverageRTT”
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 17 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 18

3
 TCP Connection Management - 1 TCP Connection Management - 2
Recall: TCP sender, receiver establish Three way handshake:
connection before exchanging data segments
Step 1: client end system sends TCP SYN
• initialize TCP variables: control segment to server
– seq. #s – specifies initial seq #
– buffers, flow control info (e.g. RcvWindow)
• client: connection initiator Step 2: server end system receives SYN,
replies with SYNACK control segment
Socket clientSocket = new Socket("hostname","port
number"); – ACKs received SYN
• server: contacted by client – allocates buffers
Socket connectionSocket = welcomeSocket.accept(); – specifies server-> receiver initial seq. #
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 19 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 20

TCP Connection Management - 3 TCP Connection Management - 4

Fddfdf
Closing a connection: client server

close
FIN
client closes socket: clientSocket.close();
ACK
Step 1: client end system sends TCP FIN
close

FIN control segment to server

timed wait

ACK

Step 2: server receives FIN, replies with

ACK. Closes connection, sends FIN.
closed
d
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 21 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 22

TCP Connection Management - 5 TCP Connection Management - 6

Step 3: client receives FIN, replies with ACK.

– Enters “timed wait” - will respond with
ACK to received FINs

Step 4: server, receives ACK. Connection

closed.

Note: with small modification, can handle

simultaneous FINs.
TCP client lifecycle
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 23 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 24

4
 TCP Connection Management - 7 Recap: Stability of a Multiplexed System
Average Input Rate > Average Output Rate
=> system is unstable!

How to ensure stability ?

1. Reserve enough capacity so that
demand is less than reserved capacity
2. Dynamically detect overload and adapt
TCP server lifecycle either the demand or capacity to resolve
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 25 overload
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 26

Congestion Problem in Packet Switching The

λ
Congestion Problem
i µ
λ outstrips
µ available capacity
i
10 Mbs statistical multiplexing •Problem: demand
A Ethernet C λ1

1.5 Mbs Demand Capacity

B
queue of packets 45 Mbs
waiting for output λn
link
• If information about λ i , λ and µ is
D E known in a central location where
q Cost: self-descriptive header per-packet,
buffering and delays for applications. control of λ i or µ can be effected
with zero time delays,
q Need to either reserve resources or
dynamically detect/adapt to overload for stability – the congestion problem is solved!
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 27 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 28

The Congestion Problem

The Congestion Problem
(Continued)
• Static fixes may not solve congestion
• Problems: – a) Memory becomes cheap (infinite memory)
– Incomplete information (eg: loss
indications)
– Distributed solution required No buffer Too late
– Congestion and
control/measurement locations q b) Links become cheap (high speed links)?
different All links 19.2 kb/s Replace with 1 Mb/s

– Time-varying, heterogeneous time- S S S S S S S S

delay File Transfer Time = 7 hours
File Transfer time = 5 mins
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 29

5
 The Congestion Problem
Principles of Congestion Control
(Continued)
Congestion:
• c) Processors become cheap • informally: “too many sources sending too
(fast routers & switches) much data too fast for network to handle”
• different from flow control (receiver overload)!
A C
S • manifestations:
B D – lost packets (buffer overflow at routers)
Scenario: All links 1 Gb/s.
– long delays (queuing in router buffers)
A & B send to C
=> “high-speed” congestion!! • a top-10 problem!
(lose more packets faster!)
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 32

Causes/costs of congestion: Causes/costs of congestion:

scenario 1 scenario 2
• two senders, two • one router, finite buffers
receivers
• sender retransmission of lost packet
• one router,
infinite buffers
• no
retransmission
• large delays
when
congested
• maximum
achievable
throughput
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 33 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 34

Causes/costs of congestion: Causes/costs of congestion:

scenario 2 (continued) scenario 3

“Costs” of congestion: Another “cost” of congestion:

• More work (retrans) for given “goodput” • when packet dropped, any “upstream
• Unneeded retransmissions: link carries transmission capacity used for that packet
multiple copies of pkt due to spurious was wasted!
timeouts
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 35 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 36

6
 Approaches towards Approaches towards
congestion control - 1 congestion control - 2

• Two broad approaches towards Network-assisted congestion

congestion control: control:
End-end congestion control: • routers provide feedback to end
• no explicit feedback from network systems
– single bit indicating congestion
• congestion inferred from end-system
(SNA, DECbit, TCP/IP ECN, ATM)
observed loss, delay
• approach taken by TCP – explicit rate sender should send at

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 37 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 38

TCP congestion control - 1 TCP congestion control - 2

• end-end control (no network assistance)

• transmission rate limited by congestion • w segments, each with MSS
window size, Congwin, over segments:
bytes sent in one RTT:
w * MSS
throughput = Bytes/sec
RTT

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 39 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 40

Additive Increase/Multiplicative
TCP congestion control - 3
Decrease (AIMD) Policy
• “Probing” for usable bandwidth: • For stability:
– Window flow control: avoid receiver – rate-of-decrease > rate-of-increase
overrun – Decrease performed “enough” times as
– Dynamic window congestion control: long as congestion exists
avoid/control network overrun • AIMD policy satisfies this condition,
• Policy: provided packet loss is congestion
indicator
– Increase Congwin until loss (congestion)
window
– Loss => decrease Congwin, then begin
probing (increasing) again

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 41 Rensselaer Polytechnic Institute
time
© Shivkumar Kalvanaraman & © Biplab Sikdar 42

7
 Fairness Fairness Analysis

Fairness goal: if N TCP sessions

share same bottleneck link, each
should get 1/N of link capacity
TCP connection 1

bottleneck
TCP
router
connection 2
capacity R

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 43 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 44

AIMD Converges to Fairness TCP congestion control - 4

• TCP uses AIMD policy in “steady state”
• Two “phases”
– Transient phase: aka “Slow start”
– Steady State: aka “Congestion avoidance”
• Important variables:
– Congwin
– threshold: defines threshold between two
slow start phase, congestion avoidance
phase

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 45 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 46

TCP Slowstart - 1 TCP Slowstart - 2

Slowstart algorithm
• asdf Host A Host B
initialize: Congwin = 1 one segm
ent
for (each segment ACKed)
RTT

Congwin++
two segm
ents
until (loss event OR
CongWin > threshold)
four segm
ents
• Exponential increase (per RTT) in window
size (not so slow!)
• Loss event: timeout (Tahoe TCP) and/or
time
three duplicate ACKs (Reno TCP)

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 47 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 48

8
 TCP Dynamics TCP Congestion Avoidance - 1
Congestion avoidance
1st RTT 2nd RTT 3rd RTT 4th RTT /* slowstart is over */
/* Congwin > threshold */
• Rate of acks determines rate of Until (loss event) {
every w segments ACKed:
packets : “Self-clocking” property. Congwin++
}
100 Mbps 10 Mbps threshold = Congwin/2
Congwin = 1
Router 1
Q perform slowstart

1: TCP Reno skips slowstart (aka fast recovery) after

three duplicate ACKs and performs close to AIMD
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 49 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 50

TCP Congestion Avoidance - 2 TCP window dynamics (more)

Receiver Window
Congestion Timeout
Window Idle
ssthresh
(cwnd) Interval

1
Time (units of RTTs)

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 51 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 52

TCP latency modeling - 1 TCP latency modeling - 2

Notation, assumptions:
Q: How long does it take to • Assume one link between client and
receive an object from a Web server of rate R
• Assume: fixed congestion window, W
server after sending a request? segments
• TCP connection establishment • S: MSS (bits)
• data transfer delay • O: object size (bits)
• no retransmissions (no loss, no
corruption)

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 53 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 54

9
 TCP latency modeling - 3 TCP latency modeling - 4
Two cases to consider:
• 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 Case 1: latency = 2RTT + O/R
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 55 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 56

TCP latency modeling:

TCP latency modeling - 5
slow start - 1
• Now suppose window grows according to
slow start.
• Will show that the latency of one object of
size O is:
K = O/WS
O  S S
Latency = 2 RTT + + P  RTT +  − ( 2 P − 1)
R  R R

where P is the number of times TCP stalls at

Case 2: latency = 2RTT + O/R server:
+ (K-1)[S/R + RTT - WS/R]
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 57 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 58

TCP latency modeling: TCP latency modeling:

slow start - 2 slow start - 3
initiate TCP
connection

Example:
P = min{Q, K − 1}
request
object
first window
= S/R
O/S = 15 segments
RTT
second window
= 2S/R

- where Q is the number of times the server K = 4 windows third window

would stall if the object were of infinite = 4S/R

size. Q=2
fourth window
= 8S/R

- and K is the number of windows that cover P = min{K-1,Q} = 2

the object. object
complete
transmission
Server stalls P=2 times. delivered
time at
time at server
client

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 59 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 60

10
 TCP latency modeling: TCP latency modeling:
slow start - 4 slow start - 5
S
+ RTT = time from when server starts to send segment
R P
O
until server receives acknowledgement latency =
R
+ 2 RTT + ∑ stallTime p
p=1

k −1 S O P
S S
= time to transmit the kth window ∑ [ R + RTT − 2
k −1
2 = + 2 RTT + ]
R R k =1 R
O S S
+ = + 2 RTT + P[ RTT + ] − (2 P − 1)
S k −1 S R R R
+ RTT − 2 = stall time after the kth window
R R 


Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 61 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 62

Sample Results Summary: Chapter 3

Minimum Latency: Latency with slow
R O/R P
O/R + 2 RTT start

28 Kbps 28.6 sec 1 28.8 sec 28.9 sec

• Principles behind transport layer services:
• multiplexing/demultiplexing
100 Kbps 8 sec 2 8.2 sec 8.4 sec
• reliable data transfer
1 Mbps 800 5 1 sec 1.5 sec • flow control
msec
• congestion control
10 Mbps 80 msec 7 0.28 sec 0.98 sec
• Instantiation and implementation in the
Internet
• UDP, TCP
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 63 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 64

11