E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
1
EE 586 Communication andSwitching Networks
Lecture 11
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-2
TCP ACK generation [RFC 1122, RFC 2581]
event at receiver
arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
arrival of in-order segment with
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
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-3
TCP ACK generation [RFC 1122, RFC 2581]
event at receiver
arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
arrival of in-order segment with
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
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-4
TCP ACK generation [RFC 1122, RFC 2581]
event at receiver
arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
arrival of in-order segment with
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
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-5
TCP ACK generation [RFC 1122, RFC 2581]
event at receiver
arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
arrival of in-order segment with
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
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-6
TCP ACK generation [RFC 1122, RFC 2581]
event at receiver
arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
arrival of in-order segment with
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
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-7
TCP fast retransmit
time-out period oftenrelatively long:
long delay beforeresending lost packet
detect lost segmentsvia duplicate ACKs.
sender often sendsmany segments back-to-back
if segment is lost, therewill likely be manyduplicate ACKs.
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-8
TCP fast retransmit
time-out period oftenrelatively long:
long delay beforeresending lost packet
detect lost segmentsvia duplicate ACKs.
sender often sendsmany segments back-to-back
if segment is lost, therewill likely be manyduplicate ACKs.
if sender receives 3ACKs for same data
(triple duplicate ACKs),
resend unackedsegment with smallestseq #
likely that unackedsegment lost, so dontwait for timeout
TCP fast retransmit
(triple duplicate ACKs),
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-9
X
fast retransmit after sender
receipt of triple duplicate ACK
Host B
Host A
Seq=92, 8 bytes of data
ACK=100
timeout
ACK=100
ACK=100
ACK=100
TCP fast retransmit
underline_base
Seq=100, 20 bytes of data
Seq=100, 20 bytes of data
desktop_computer_stylized_medium
desktop_computer_stylized_medium
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
Finally, the last question!
Three Questions:
How do, say a webserver at port 80, differentiateand response to two different clients? (3.2, 3.3)
How can an end-to-end protocol eliminate ALLnetwork error along the way? (3.4, 3.5)
How can an end-to-end protocol prevent thecollapse of the Internet (3.6, 3.7)
Flow control – fast sender will not crash slow receiver
Congestion control – how to play nice in the dark
10
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-11
TCP flow control
application
process
TCP socket
receiver buffers
TCP
code
IP
code
application
OS
receiver protocol stack
application may
remove data from
TCP socket buffers ….
… slower than TCP
receiver is delivering
(sender is sending)
underline_base
desktop_computer_stylized_medium
from sender
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-12
TCP flow control
application
process
TCP socket
receiver buffers
TCP
code
IP
code
application
OS
receiver protocol stack
application may
remove data from
TCP socket buffers ….
… slower than TCP
receiver is delivering
(sender is sending)
from sender
receiver controls sender, sosender will not overflowreceivers buffer by transmittingtoo much,  too fast
flow control
underline_base
desktop_computer_stylized_medium
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-13
TCP flow control
underline_base
Dark upward diagonal
buffered data
free buffer space
rwnd
RcvBuffer
TCP segment payloads
to application process
receiver advertises freebuffer space by includingrwnd value in TCP headerof receiver-to-sendersegments
RcvBuffer size set viasocket options (typical defaultis 4096 bytes)
many operating systemsautoadjust RcvBuffer
sender limits amount ofunacked (in-flight) data toreceiverrwnd value
guarantees receive bufferwill not overflow
receiver-side buffering
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-14
congestion:
informally: too many sources sending too muchdata 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!
underline_base
Principles of congestion control
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Goals of Congestion Control
Efficiency criterion – to maximize the overallthroughput of the network
= each flow should control their sending rates to preventcongestion collapse
Fairness criterion – (for single bottleneck) eachflow should have equal share of bandwidth
Transport Layer
3-15
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-16
TCP congestion control:
rgoal:  TCP sender should transmit as fast as possible,but without congesting network
mQ: how to find rate just below congestion level
rdecentralized: each TCP sender sets its own rate, basedon implicit feedback:
mACK: segment received (a good thing!), network notcongested, so increase sending rate
mlost segment: assume loss due to congested network,so decrease sending rate
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-17
underline_base
Rate(Window)-based control
sender limits transmission:
cwnd is dynamic, function ofperceived networkcongestion
TCP sending rate:
roughly: send cwndbytes, wait RTT forACKS, then sendmore bytes
last byte
ACKed
sent, not-yetACKed
(in-flight)
last bytesent
cwnd
LastByteSent-
LastByteAcked
<
cwnd
sender sequence number space
rate
~
cwnd
RTT
bytes/sec
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
Window size & Sending Rate
first packet bit transmitted, t = 0
sender
receiver
RTT
last bit transmitted, t = L / R
first packet bit arrives
last packet bit arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
18
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-19
Joint fairness and efficiency goal: if 2 flows share samebottleneck link of bandwidth R, each should have averagerate of R/2
Flow 1, R1
bottleneck
router
capacity R
Flow 2, R2
Two flows - single bottleneck
R2
 Sending rate of Flow 1
Sending rate of Flow 2
R1
R1+R2<R
Inefficienct
R1+R2=R
Efficient but
Unfair to flow 1
R1+R2=R
Efficient but
Unfair to flow 2
R1+R2>R
Heavy loss
Congestion collapse
R1=R2=R/2
Efficient
and Fair
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Distributed Control of Sending Rates
Each sender is not awareof the presence of othersenders.
Each sender can sensecongestion due to lossevents.
Distributed control
Increase sending rate whenno loss
Decrease sending ratewhen loss
Same action for everysender
Additive : R  
Multiplicative: cR for c>1 or c<1
3-20
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Which is optimal?
3-21
Additive Increase,
Additive Decrease
Mult. Increase,
Mult. Decrease
Multi. Increase,
Additive Decrease
Additive Increase,
Multi. Decrease
Starting Scenario 1
Starting Scenario 2
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Which is optimal?
3-22
Additive Increase,
Additive Decrease
Mult. Increase,
Mult. Decrease
Multi. Increase,
Additive Decrease
Additive Increase,
Multi. Decrease
Starting Scenario 1
Starting Scenario 2
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Which is optimal?
3-23
Additive Increase,
Additive Decrease
Mult. Increase,
Mult. Decrease
Multi. Increase,
Additive Decrease
Additive Increase,
Multi. Decrease
Starting Scenario 1
Starting Scenario 2
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Which is optimal?
3-24
Additive Increase,
Additive Decrease
Mult. Increase,
Mult. Decrease
Multi. Increase,
Additive Decrease
Additive Increase,
Multi. Decrease
Starting Scenario 1
Starting Scenario 2
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Which is optimal?
3-25
Additive Increase,
Additive Decrease
Mult. Increase,
Mult. Decrease
Multi. Increase,
Additive Decrease
Additive Increase,
Multi. Decrease
Starting Scenario 1
Starting Scenario 2
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Bandwidth Probing (steady state)
underline_base
AIMD: additive increase multiplicative decrease
approach: sender increases transmission rate (windowsize), probing for usable bandwidth, until loss occurs
additive increase: increase  cwnd by 1 MSS everyRTT until loss detected (i.e. rate increase by 1/RTT)
multiplicative decrease: cut cwnd in half after loss(i.e. rate decrease by a factor of ½)
cwnd: TCP sender
congestion window size
AIMD saw tooth
behavior: probing
for bandwidth
additively increase window size …
…. until loss occurs (then cut window in half)
time
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-27
TCP Slow Start
when connection begins,raise rate exponentiallyuntil first loss event:
initially cwnd = 1 MSS
double cwnd every RTT
done by incrementingcwnd for every ACKreceived
Back to additive increaseafter hitting ½ of old rate
summary: initial rate isslow but ramps upexponentially fast
Host A
one segment
RTT
Host B
time
two segments
four segments
underline_base
desktop_computer_stylized_medium
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-28
Q: when should theexponentialincrease switch tolinear?
A: when cwnd getsto 1/2 of its valuebefore timeout.
 
Implementation:
variable ssthresh
on loss event, ssthreshis set to 1/2 of cwnd justbefore loss event
underline_base
TCP: switching from slow start to CA
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-29
underline_base
TCP throughput
avg. TCP thruput as function of window size, RTT?
ignore slow start, assume always data to send
W: window size (measured in bytes) where loss occurs
avg. window size (# in-flight bytes) is ¾ W
avg. thruput is 3/4W per RTT
W
W/2
avg TCP thruput =
3
4
W
RTT
bytes/sec