COM210: Computer Networks (CN) COM210: Computer Networks (CN) P P

COM210: Computer
p Networks (CN)
( )
Chapter 3: TCP
Dr Ahmad Al-Zubi
King Saud University - Dr Ahmad Al-Zubi 1

TCP: Overview
• Point-to-point:
– one sender,
sender one receiver
• Reliable, in-order byte steam:
– no “message boundaries”
– But TCP chops it up into segments for
transmission internally
• Pipelined (window) flow control:
– Window size decided by receiver and
network
• Send & receive buffers
TCP: Overview
application application
writes data reads data
socket socket
door door
TCP TCP
send buffer receive buffer
segment

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

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: p
push data now len used
U AP R S F rcvr window size
(generally not used) #bbytes
t
checksum ptr urgent data
rcvr willing
RST, SYN, FIN: to accept
Options (variable length)
connection estab
(setup, teardown
commands)
application
IInternet
t t data
checksum (variable length)
(as in UDP)

TCP seq. #’s and ACKs (I)
Sequence Numbers:
– byte stream “number”
number of first byte in
segment’s data
ACKs:
– seq # of next byte expected from other side
– cumulative ACK
Q: how receiver handles out-of-order segments

– A: TCP spec doesn’t say, - up to
implementor
TCP Seq. #’s and ACKs (II)
Host A Host B
User
types
‘C’
host ACKs
receipt of
‘C’ echoes
‘C’, h
back ‘C’
hostt ACKs
h ACK
receipt
of echoed
‘C’
simple
p telnet scenario

Temporal Redundancy Model
Packets • Sequence Numbers
• CRC or Checksum
Timeout
• ACKs
Status Reports
• NAKs,
NAKs
• SACKs
• Bitmaps
Retransmissions
• Packets
• FEC information

Status Report Design
• Cumulative acks:
– Robust to losses on the reverse channel
– Can work with go-back-N retransmission
– Cannot pinpoint blocks of data which are
lost
• The first lost packet can be pinpointed
because the receiver would generate
duplicate
p acks

TCP: reliable data transfer (I)
event: data received

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

with ACK # y
ACK processing
00 sendbase = initial_sequence number
01 nextseqnum = initial_sequence number
02
03 loop
l (forever)
(f ){
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
09 nextseqnum = nextseqnum + length(data)
reliable 10
11
event: timer timeout for segment with sequence number y
retransmit segment with sequence number y
12 compute new timeout interval for segment y
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 */
transfer (II) 16
17
18
cancel all timers for segments with sequence numbers < y
sendbase = y
}
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) {
Simplified 22 /* TCP fast retransmit */
23 resend segment with sequence number y
TCP
C 24
25 }
restart timer for segment y
sender 26 } /* end of loop forever */

TCP ACK generation
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
higher than expect seq.
seq # of next expected byte
gap detected!
arrival of segment that immediate ACK if segment starts

partially
ti ll or completely
l t l fills
fill gap att lower
l end
d off gap
TCP: retransmission scenarios
Host A Host B Host A Host B
Seq=92 timeout
eout
out
timeo
eq=100 time
X
loss
Se
time
time ost ACK
lost K scenario
sc nar o premature timeout,,
p
cumulative ACKs
TCP Flow Control
flow control receiver: explicitly
sender won’t overrun informs sender of
receiver’s
receiver s buffers by free buffer space
transmitting too much,
too fast
– RcvWindow
field in TCP
RcvBuffer = size or TCP Receive Buffer segmentt
RcvWindow = amount of spare room in Buffer sender: keeps the
amount of
transmitted,
unACKed data less
tthan
a most
ost recently
ece t y
received
RcvWindow
receiver buffering
Timeout and RTT Estimation
• Timeout: for robust detection of
packet loss
• Problem: How long should timeout
be ?
– Too long =>> underutilization
– Too short => wasteful
retransmissions
– Solution: adaptive timeout: based on
estimate
ti t off max RTT
How to estimate max RTT?
• RTT = prop + queuing delay
– Queuing delay highly variable
– So, different samples of RTTs will give
different random values of q
queuingg delay
y
• Chebyshev’s
y Theorem:
– MaxRTT = Avg RTT + k*Deviation
– Error probability is less than 1/(k**2)
– Result true for ANY distribution of
samples

Round Trip Time and Timeout (II)
Q: how to estimate RTT?
• SampleRTT: measured time from segment
transmission until ACK receipt
– ignore retransmissions, cumulatively
ACKed segments
• SampleRTT
S l RTT will
ill vary wildly
ildl =>
> wantt
estimated RTT “smoother”
– use several recent measurements
measurements, not
just current SampleRTT to calculate
“AverageRTT”
AverageRTT
TCP Round Trip Time and
Timeout (III)
AverageRTT
g = (1-x)*AverageRTT
( ) g + x*SampleRTT
p
• Exponential weighted moving average (EWMA)

• influence of given
g sample
p decreases
exponentially fast; x = 0.1
Setting
g the timeout
• AverageRTT plus “safety margin” proportional to
variation
Timeout = AverageRTT + 4*Deviation
Deviation = (1-x)*Deviation + x*|SampleRTT- AverageRTT|

TCP Connection Management - 1
Recall: TCP sender, receiver establish
connection before exchanging
g g data segments
g
• initialize TCP variables:

– seq. #s
– buffers, flow control info (e.g. RcvWindow)
• client:
li t connection
ti initiator
i iti t
Socket clientSocket = new Socket("hostname","port
number );
number");
• server: contacted by client
Socket connectionSocket = welcomeSocket
welcomeSocket.accept();
accept();
Three way handshake:
Step 1: client end system sends TCP SYN
control segment to server
– specifies initial seq #
Step 2: server end system receives SYN

SYN,
replies with SYNACK control segment
– ACKs received SYN
– allocates buffers
– specifies server->
server > receiver initial seq. #
Closing a connection:
client closes socket: clientSocket.close();
()
Step 1: client end system sends TCP

FIN control segment to server
St 2:
Step 2 server receives FIN, replies with
ACK. Closes connection, sends FIN.

Fddfdf client server
close
close
timed wait
closed
d
Step 3: client receives FIN

FIN, replies with ACK
ACK.
– Enters “timed wait” - will respond with
ACK to
t received
i d FINs
FIN
Step 4: server, receives ACK. Connection

closed.
Note: with small modification, can handle

simultaneous FINs.

TCP client
li t lifecycle
lif l
TCP server lifecycle

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
d
demand d is
i less
l than
th reserved d capacity
it
2. Dynamically detect overload and adapt
either the demand or capacity to resolve
overloadKing Saud University - Dr Ahmad Al-Zubi 26
Congestion Problem in Packet Switching
10 Mbs statistical multiplexing
A Ethernet C
1.5 Mbs
B
queue of packets 45 Mbs
Mb
waiting for output
link
D E
Cost: self-descriptive header per-packet,
buffering and delays for applications.
Need to either reserve resources or
dynamically detect/adapt to overload for stability
The
λ
Congestion Problem
i μi
•Problem:
P bl d λ d outstrips
demand t t iμ available
il bl capacity
it
λ1
Demand Capacity
λn
• If information about λi , λ and μ is
known in a central location where
control of λi or μ can be effected
with zero time delays,
– the
h congestion
i problem
bl is
i solved!
l d!
The Congestion Problem
(Continued)
• Problems:
– Incomplete information (eg: loss
indications)
– Distributed solution required
– Congestion
g and
control/measurement locations
different
– Time-varying, heterogeneous time-
delay
• Static fixes may not solve congestion
– a)) Memory
y becomes cheap
p (infinite
( memory)
y)
No buffer Too late
b) Links become cheap (high speed links)?

All links 19.2 kb/s Replace with 1 Mb/s
S S S S S S S S
File Transfer time = 5 mins File Transfer Time = 7 hours
(Continued)
• c) Processors become cheap
(fast routers & switches)
A C
S
B D
Scenario: All links 1 Gb/s.
A & B send to C
=> “high-speed” congestion!!
(lose more packets faster!)
Principles of Congestion Control
Congestion:
• informally: “too many sources sending too
much data too fast for network to handle”
• different
diff t from
f flow
fl control
t l (receiver
( i overload)!
l d)!
• manifestations:
– lost packets (buffer overflow at routers)
– long delays (queuing in router buffers)
• a top-10 problem!

Causes/costs of congestion:
scenario 1
• two senders, two
receivers
i
• one router,
infinite buffers
• no
retransmission
• large delays
when
congested
• maximum
achievable
throughput
scenario 2
• one router, finite buffers
• sender retransmission of lost packet

scenario 2 (continued)
“Costs” of congestion:
• More work (retrans) for given “goodput”
goodput
• Unneeded retransmissions: link carries
multiple
p copies
p of pkt
p due to spurious
p
timeouts
scenario 3
Another “cost” of congestion:

• when packet dropped, any “upstream
transmission capacity used for that packet
was wasted!
Approaches towards
congestion control - 1
• Two broad approaches towards

congestion
g control:
End-end congestion control:
• no explicit
li it feedback
f db k from
f network
t k
• congestion inferred from end-system
observed loss, delay
pp
• approach taken byy TCP
Approaches towards
congestion control - 2
Network-assisted congestion
control:
• routers provide feedback to end
systems
– single bit indicating congestion
(SNA DECbit,
(SNA, DECbit TCP/IP ECN,
ECN ATM)
– explicit rate sender should send at

TCP congestion control - 1
• end-end control ((no network assistance))

• transmission rate limited by congestion
window size, Congwin, over segments:

• w segments, each with MSS

bytes sent in one RTT:
w * MSS
th
throughput
h t= Bytes/sec
RTT

• “Probing” for usable bandwidth:
– Window flow control: avoid receiver
overrun
– Dynamic window congestion control:
avoid/control network overrun
• Policy:
– Increase Congwin until loss (congestion)
– Loss => decrease Congwin,
Congwin then begin
probing (increasing) again

Additive Increase/Multiplicative
Decrease (AIMD) Policy
• For stability:
– rate-of-decrease
rate of decrease > rate
rate-of-increase
of increase
– Decrease performed “enough” times as
long as congestion exists
• AIMD policy satisfies this condition,
provided packet loss is congestion
indicator
window
time
Fairness
Fairness g
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

Fairness Analysis

AIMD Converges to Fairness

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

TCP Slowstart - 1
Slowstart algorithm
iinitialize:
iti li Congwin
C i =1
for (each segment ACKed)
Congwin++
until (loss event OR
CongWin > threshold)
• Exponential increase (per RTT) in window

size (not so slow!)
• Loss event: timeout (Tahoe TCP) and/or
three duplicate ACKs (Reno TCP)

TCP Slowstart - 2
• asdf Host A Host B
RTT
time

TCP Dynamics
1st RTT 2nd RTT 3rd RTT 4th RTT
• Rate of acks determines rate of

packets : “Self
Self-clocking
clocking” property.
property
100 Mbps 10 Mbps
Router
Q

TCP Congestion Avoidance - 1
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

p slowstart (aka
( fast recovery)
y) after
three duplicate ACKs and performs close to AIMD
TCP Congestion Avoidance - 2

TCP window dynamics (more)
Receiver Window
Congestion Timeout
Window Idle
ssthresh
(cwnd) Interval
1
Time (units of RTTs)

TCP latency modeling - 1
Q: How long does it take to

receive an object from a Web
server after sending a request?
• TCP connection
ti establishment
t bli h t
• data transfer delay

Notation, assumptions:
• Assume one link between client and
server of rate R
• Assume: fixed congestion window, W
segments
• S: MSS (bits)
• O: object size (bits)
• no retransmissions
t i i (no
( loss,
l no
corruption)

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

K = O/WS
Case 2: latency = 2RTT + O/R

+ (K-1)[S/R
(K 1)[S/R + RTT - WS/R]
TCP latency modeling:
slow start - 1
• Now suppose window grows according to
slow start.
• Will show that the latency
y of one object
j of
size O is:
O ⎡ S⎤ S
Latency = 2 RTT + + P ⎢ RTT + ⎥ − (2 − 1)
P
R ⎣ R⎦ R
where
h P is
i the
th number
b off times
ti TCP stalls
t ll att
server:

slow start - 2
P = min{Q, K − 1}
- where Q is the number of times the server
would stall if the object
j were of infinite
size.
- andd K is
i the
h number
b off windows
i d that
h cover
the object.

slow start - 3
initiate TCP
connection
Example:
request
object
first window
= S/R
O/S = 15 segments RTT
second window
= 2S/R
K = 4 windows third window

= 4S/R
Q=2
fourth window
= 8S/R
P = min{K-1,Q}
min{K 1 Q} = 2
complete
object transmission
Server stalls P=2 times. delivered
time at
time at server
client

slow start - 4
S
+ RTT = time from when server starts to send segment
R
until server receives acknowledgement
k −1 S
2 = time to transmit the kth window
R
+
⎡S k −1 S ⎤
⎢⎣ R + RTT − 2 R ⎥⎦ = stall time after the kth window

slow start - 5
P
O
latency = + 2 RTT + ∑ stallTimep
R p =1
P
O S k −1 S
= + 2 RTT + ∑ [ + RTT − 2 ]
R k =1 R R
O S S
= + 2 RTT + P[ RTT + ] − (2 − 1)
P
R R R

Sample Results
Minimum Latency: Latency with slow
R O/R P
O/R + 2 RTT
O/ start
28 Kbps 28.6 sec 1 28.8 sec 28.9 sec
100 Kbps 8 sec 2 8.2 sec 8.4 sec
1 Mbps 800 5 1 sec 1.5 sec

msec
10 Mbps
p 80 msec 7 0.28 sec 0.98 sec

Summary: Chapter 3
• Principles behind transport layer services:

• multiplexing/demultiplexing
• reliable data transfer
• flow control
• congestion control
• Instantiation
I t ti ti andd implementation
i l t ti ini the
th
Internet
• UDP,
UDP TCP

COM210: Computer Networks (CN) COM210: Computer Networks (CN) P P

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

COM210: Computer Networks (CN) COM210: Computer Networks (CN) P P

Uploaded by

Copyright:

Available Formats

COM210: Computer

King Saud University - Dr Ahmad Al-Zubi 1

King Saud University - Dr Ahmad Al-Zubi 3

King Saud University - Dr Ahmad Al-Zubi 4

King Saud University - Dr Ahmad Al-Zubi 5

Q: how receiver handles out-of-order segments

King Saud University - Dr Ahmad Al-Zubi 7

King Saud University - Dr Ahmad Al-Zubi 8

King Saud University - Dr Ahmad Al-Zubi 9

event: data received

event: ACK received,

sender 26 } /* end of loop forever */

King Saud University - Dr Ahmad Al-Zubi 11

Event TCP Receiver action

in-order segment arrival, immediately send single

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

arrival of segment that immediate ACK if segment starts

King Saud University - Dr Ahmad Al-Zubi 16

• Exponential weighted moving average (EWMA)

King Saud University - Dr Ahmad Al-Zubi 18

• initialize TCP variables:

Step 2: server end system receives SYN

Step 1: client end system sends TCP

King Saud University - Dr Ahmad Al-Zubi 21

Fddfdf client server

Step 3: client receives FIN

Step 4: server, receives ACK. Connection

Note: with small modification, can handle

King Saud University - Dr Ahmad Al-Zubi 23

TCP server lifecycle

How to ensure stability ?

No buffer Too late

 b) Links become cheap (high speed links)?

King Saud University - Dr Ahmad Al-Zubi 32

King Saud University - Dr Ahmad Al-Zubi 34

Another “cost” of congestion:

• Two broad approaches towards

King Saud University - Dr Ahmad Al-Zubi 38

• end-end control ((no network assistance))

King Saud University - Dr Ahmad Al-Zubi 39

• w segments, each with MSS

King Saud University - Dr Ahmad Al-Zubi 40

King Saud University - Dr Ahmad Al-Zubi 41

King Saud University - Dr Ahmad Al-Zubi 43

King Saud University - Dr Ahmad Al-Zubi 44

King Saud University - Dr Ahmad Al-Zubi 45

King Saud University - Dr Ahmad Al-Zubi 46

• Exponential increase (per RTT) in window

King Saud University - Dr Ahmad Al-Zubi 47

• asdf Host A Host B

King Saud University - Dr Ahmad Al-Zubi 48

• Rate of acks determines rate of

100 Mbps 10 Mbps

King Saud University - Dr Ahmad Al-Zubi 49

1: TCP Reno skips

King Saud University - Dr Ahmad Al-Zubi 51

King Saud University - Dr Ahmad Al-Zubi 52

Q: How long does it take to

King Saud University - Dr Ahmad Al-Zubi 53

King Saud University - Dr Ahmad Al-Zubi 54

• WS/R < RTT + S/R: wait for ACK

Case 1: latency = 2RTT + O/R

b) Links become cheap (high speed links)?