Congestion Control: Part 2

Gaurav S. Kasbekar
Dept. of Electrical Engineering
IIT Bombay

1-1
References
 Slides by Kurose and Ross available at:
http://ctas.poly.asu.edu/millard/CET459/lectno/K%
20-%20R%20stuff/index.html

1-2
 Congestion Control Problem
 Multiple flows (e.g., file transfers) across a
network
 set of active flows varies with time
 Each sender must dynamically adapt
transmission rate to available bandwidth

3-3
Approaches towards congestion control
Two broad approaches towards congestion control:

End-to-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
packet loss, delay  explicit rate the router
 Approach taken by TCP can support
 Approach taken by ATM

3-4
 Modes of Feedback in N/w Assisted CC

 Direct Feedback: Router sends a packet containing

congestion indication/ explicit rate field to sender
 Via receiver: router adds this info. to data
packets; echoed in ACKs by destination
 delay in feedback
 Reliable Data Transfer in TCP
 Recall: IP provides unreliable data transfer from
source to destination in the Internet
 TCP provides reliable data transfer
 Similar to Selective Repeat in foll. respects:
 Receiver buffers out-of-order pkts
 When timeout for a pkt occurs, sender resends only
that pkt
Difference:
❑ Cumulative ACKs used instead of Selective ACKs
o if out-of-order pkts received, ACK sent for last in-
order pkt correctly received
o so selective retransmissions by sender not possible
 Fast Retransmit
 One way sender can detect pkt loss: timeout
 But timeout interval has to be sufficiently
larger than estimated RTT
 delay in retransmission
 Suppose ACK for pkt n expected, but instead 3
duplicate ACKs received for pkt n-1
 What do they indicate?
 Probably pkt n not received, but 3 subsequent
pkts correctly received at receiver
 Sender infers that pkt n was lost and
retransmits it immediately
3-7
 TCP Congestion Control
 End-to-end scheme
 implemented by sender without any help from
routers
 Components of TCP Congestion Control:
1) Congestion level estimation
2) Rate adaptation

3-8
 TCP Congestion Control
 Sender does not know amount of free bandwidth at
routers along path
 When sender sends a data pkt, either ACK received
or pkt loss detected
 Need to infer congestion level using just this info.
Idea:
 Pkt loss indicates high congestion ⟹ reduce rate
 ACK received for previously unACKed pkt ⟹
increase rate
 Adaptive algorithm
Achieving a Desired Send Rate r
 Suppose sender wants to send at avg. rate
r pkts/sec
 One way: send one pkt every 1/r sec
 Want to achieve same send rate using a
window

3-10
 Achieving a Desired Send Rate r
 Assume constant RTT, no corrupted or lost pkts or ACKs
 Pkt transmission times negligible compared to RTT and
window size N is used
 Avg rate r:
 N / RTT
 Summary
 We can adjust the send rate by adjusting
window size N
 When pkt loss detected, decrease N
 When new ACK received, increase N
 Notation: henceforth, denote window size
by Cong_Win
 Operation

States:
 Slow Start: Cong_Win increased exponentially
 Congestion Avoidance: Cong_Win increased linearly
 Fast Recovery: a transit state; duration ≤1 RTT (approx.)
 Slow Start
 When sender starts data transfer, has no
idea how congested network is
 So starts cautiously: Cong_Win = 1
 But corresponding rate may be much lower
than available bandwidth
 E.g., if pkt size = 500 bytes, RTT = 200 ms,
then rate = only 20 kbps
 Need a way to rapidly increase Cong_Win
when new ACKs received

3-14
 Slow Start

 Cong_Win doubled every round

3-15
 Slow Start
 Want to double Cong_Win every round
 But at a time, sender receives only one new
ACK; need a rule for updating Cong_Win
upon receipt to effectively achieve
doubling every round
 Cong_Win increased by 1 each time a new
ACK is received

3-16
 Slow Start
 Cong_Win increases very rapidly in slow start
 When should slow start end?
 Should certainly end when pkt loss detected
 Recall: pkt loss inferred from:
i. timeout and
ii. 3 duplicate ACKs
 Both indicate congestion, but more severe in (i)
 If timeout occurs, sstresh = Cong_Win/2, Cong_Win =1, lost
pkt resent and sender stays in Slow Start
 Half the Cong_Win value at which congestion was detected
is stored (in sstresh)
 When sender crosses sstresh again, not safe to keep
increasing Cong_Win exponentially
 switch to Congestion Avoidance state 3-17
 Slow Start
 Suppose pkt loss detected via 3 dup. ACKs
 Sender sets sstresh = Cong_Win/2,
Cong_Win = sstresh + 3, resends lost pkt
and goes to Fast Recovery

3-18
 Congestion Avoidance
 Recall: switch to CA when Cong_Win
exceeds sstresh
 Not safe to increase Cong_Win
exponentially in CA
 Cong_Win increased by 1 every RTT
 Update rule:
 Cong_Win increased by 1/Cong_Win each time a
new ACK is received
 When should CA end?
 Ends when pkt loss occurs; same actions as
in Slow Start taken
 Fast Recovery
 Recall: when pkt loss detected via 3 dup. ACKs, sender
retransmits pkt and switches to fast recovery
 Transit state sender stays in before switching to SS or CA
 duration at most 1 RTT (approx.)
 Three possible events in Fast Recovery:
1) Timeout occurs
o set sstresh = Cong_Win/2, Cong_Win = 1, retransmit lost pkt and
go to Slow Start
2) New ACK received
o set Cong_Win = sstresh and go to Congestion Avoidance (fast
recovery)
3) More dup. ACKs received: increase Cong_Win by 1 each
time, transmit new pkts as allowed, stay in Fast
Recovery
 Queuing Delays
 When congestion in network increases,
queuing delays increase
 Does TCP’s rate adaptation algorithm take
queuing delays into account?
 Yes, since RTT increases in queuing delay
 Rate (window size) increased slowly if queuing
delays large and vice-versa

3-21
FSM
 Flow Control in TCP
 Flow control: making sure that receiver
always has enough memory in buffer to
store data pkts sent by sender
 To add flow control to TCP:
 Receiver sends an integer “Flow_Win” to
sender during initial handshake and
includes it in every ACK
 equal to amt of free space in receiver buffer
 Sender uses window size = min(Flow_Win,
Cong_Win)