Flow vs. congestion control

1
Flow vs. congestion control

• Flow control
• Keeping a fast sender from overrunning a slow
  receiver
• Congestion control
• Keeping a set of senders from sending to much
  data into the network because of lack of
  resources at some point
• We will look at how TCP achieves flow and
  congestion control

2
TCP Reliable byte stream
Reliable ? Messages are ACKed
3
TCP header format
4
Data flow, ACKs, window advertisement
Receiver ACKs data received also sends
(advertises) receiver buffer information
5
Three-way handshake
6
End-to-end flow control in TCP
Receive buffer
Send buffer
7
TCP Flow Control

• Receive side of TCP connection has a receive
  buffer

• Speed-matching service matching the send rate
  to the receiving applications drain rate

• Application process may be slow at reading from
  buffer

Kurose Ross
8
TCP Flow control how it works (simplified)

• Receiver advertises spare room by including value
  of RcvWindow in segments (AdvertisedWindow field)
• Sender limits unACKed data to RcvWindow
• guarantees receive buffer doesnt overflow

• (Suppose TCP receiver discards out-of-order
  segments)
• spare room in buffer
• RcvWindow
• RcvBuffer-LastByteRcvd - LastByteRead

Kurose Ross
9
TCP congestion control

• An end-to-end scheme
• Send packets into the network and react to packet
  losses
• Determine how much capacity is available in the
  network
• As connections come and go, available bandwidth
  changes over time
• Any given source must be able to adjust the
  number of packets in transit

10
Additive increase/multiplicative decrease (AIMD)

• MaxWindowMinCongestionWindow, AdvertisedWindow
• TCP source can send no faster than the slowest
  component (network or destination) can
• A source sets CongestionWindow based on level of
  congestion it perceives in network
• Decrease window when congestion goes up
• Increase window when congestion goes down
• How does a source determine that the network is
  congested?
• Congestion ? Packet drop ? Timeout
• Set CongestionWindow to half of its previous
  value (multiplicative decrease)
• Every time source successfully sends a window of
  packets, add 1 to CongestionWindow (additive
  increase)

11
Additive increase
Packets in transit during additive increase, with
one packet being added each RTT
12
Typical sawtooth pattern of AIMD
Multiplicative decrease
Additive increase
AIMD is a necessary condition for a congestion
control mechanism to be stable (See Chiu and
Jains paper)
13
Slow start

• Additive increase is the right approach when
  source is operating close to available capacity
• When connection starts, it may take a while to
  ramp up
• TCP uses slow start to increase window rapidly
  (exponentially) from cold start!
• Slow start is slower than original TCP in which
  source starts to send as many packets as
  AdvertisedWindow allows

14
Slow start vs. additive increase
Slow start
Additive increase
15
Fast retransmit and recovery

• TCP timeout may take a long time
• Fast retransmit
• Trigger retransmission after 3 duplicate ACKs
• Fast recovery
• After fast retransmit, cut CongestionWindow in
  half rather than dropping CongestionWindow all
  the way back to 1 packet, and then continue with
  additive increase
• That is, use slow start at the beginning of a
  connection and whenever a timeout occurs.
  Otherwise, follow AIMD

16
Fast retransmit
Three duplicate ACKs
17
Congestion avoidance

• Random Early Detection (RED)
• Each router monitors its own queue length and,
  when it detects congestion is taking place,
  notifies the source to adjust its
  CongestionWindow
• Notification is implicit A packet of the source
  is dropped
• RED computes a weighted average queue length
• AvgLen(1-weight)AvgLenweightSampleLen

18
Weighted averaging in RED
Result is a low-pass filtered version of queue
length signal
19
Explicit Congestion Notification

• RED could also work with an explicit feedback
  scheme by marking packets
• Set Explicit Congestion Notification (ECN) bits
• IPs TOS field bits are used
• Such a scheme is called active queue management
• Exchange information between hosts and routers

20
Source-based congestion avoidance

• Congestion may be avoided by adjusting the
  CongestionWindow upon measuring
• RTT
• Throughput
• Since such schemes are end-to-end, no new
  mechanisms are required in routers

21
Equation-based congestion control

• Real-time applications use UDP, which is greedy
• Add TCP-like congestion control mechanism to UDP
• Result UDPCC
• Be TCP-friendly in the sense of being fair to
  competing TCP flows
• Ensure that flows behavior adheres to an
  equation that models TCPs behavior

where p is the loss rate
Note that the receiver will have to periodically
report the loss rate
22
Related reading

• Peterson Davie 5.1-5.2 (UDP/TCP background)
• Kurose Ross 3.5.5, 3.7 (TCP Flow/Congestion
  Control)
• Peterson Davie 6.3 (TCP Congestion Control)
• Peterson Davie 6.4.2 (RED)
• Peterson Davie 6.5.4 (Equation-based
  Congestion Control)