Dynamic Behavior of Slowly Responsive Congestion Control Algorithms

1
Dynamic Behavior of Slowly Responsive Congestion
Control Algorithms

• (Bansal, Balakrishnan, Floyd Shenker, 2001)

2
TCP Congestion Control

• Largely responsible for the stability of the
  internet in the face of rapid growth
• Implemented cooperatively by end hosts (not
  enforced by routers)
• Works well because most traffic is TCP

3
TCP vs Real-Time Streaming

• TCP congestion control aggresively modulates
  bandwidth
• Real-time streaming applications want smooth
  bandwidth changes
• Alternative protocols may break the internet
• What about a TCP-compatible protocol?

4
TCP Compatibility

• A compatible protocol sends data at roughly the
  same rate as TCP in the face of the same amount
  of packet loss
• This rate is measured at the steady state, when
  it has stabilized against a fixed packet loss
  rate
• In practice the packet loss rate is highly
  dynamic
• So are compatible protocols safe in practice?

5
Some Terms

• TCP-equivalent rate based on AIMD with the same
  parameters (a1, b2)
• TCP-compatible over several RTTs, rate is close
  to TCP for any given packet loss rate
• TCP-compatible protocols are slowly responsive if
  their rate changes less rapidly than TCP in
  response to a change in the packet loss rate

6
4.5 alternatives

• TCP(b) shrink window by (1/b) after packet loss
  (b2 in standard TCP)
• SQRT(b) Binomial algorithm, gentler version of
  TCP adjust window w to (1-1/b)w1/2
• RAP(b) equation-based TCP equivalent
• TFRC(b) Adjust rate based on an exponentially
  weighted moving average over b loss events
  (propose b6)
• TFRC(b) with self-clocking following a packet
  loss, limit sending rate to receivers rate of
  reception during previous round trip (default
  allows 2x sending rate). Less strict limit in
  absence of loss.

7
Metrics

• Smoothness largest ratio of new rate to old rate
  over consecutive round trips (1 is perfect)
• Fairness(d) round trips until two flows come
  within d of equal bandwidth, when one starts
  with 1 packet/RT (d10)
• f(k) fraction of bandwidth used after k round
  trips when available bandwidth has doubled
• Stabilization time time until sending rate is
  within 1.5 times steady state value at the new
  packet loss rate
• Stabilization cost Average packet loss rate
  stabilization time

8
Simulations

• Flows pass through single bottleneck router using
  RED queue management (packet drop rate is
  proportional to queue length)
• Square-wave competing flow
• Flash mobs of short-lived HTTP requests

9
Stabilization cost

• Vertical axis is logarithmic worst case cost is
  two orders of magnitude higher than TCP. Oh no!
• But proposed algorithm parameters are from 2-6
  worst case is maybe 3x? Not nearly as scary.
• b256 is much more expensive, not appreciably
  smoother

10
Stabilization time

• Remember, proposed algorithm parameters are from
  2-6.
• Large numbers included to demonstrate theoretical
  value of self-clocking?

11
Flash mob response

• In all three cases, total throughput appears
  close to total bandwidth
• Again, a demonstration of self-clocking. Where is
  TFRC(6)?
• Is TFRC-SC(256) too fair? Streaming applications
  might prefer the middle path
• This test is one TFRC flow vs 1000 HTTP flows.
  What happens if there are 10, or 100?

12
Long-term Fairness

• x-axis square-wave period, competing flow
  consumes 2/3 available bandwidth
• Link utilization is poor when square-wave period
  is .2 seconds
• TCP gets more newly-available bandwidth than TFRC
  when period is from .4 to about 10 seconds
• TCP never loses

13
Transient Fairness

• TCP(b) is inverted in these graphs W
  (1-b)W
• TCP takes a long time to converge when b is low
• TFRC takes a long time when b is high
• Neither takes very long when b is reasonable
• TFRC convergence time is less than linear with b

14
Aggressiveness

• f(k) is percent of available bandwidth used after
  k round trips, when bandwidth has doubled
• As expected, slowly-responsive protocols take
  much longer to take advantage of an increase in
  bandwidth

15
Effectiveness

• TFRCTFRC(6)
• When bandwidth oscillates over a 31 range,
  overall link utilization is comparable across
  protocols
• Over a 101 range, TFRC can perform quite badly
• Performance is good when burst period is within
  RTT history

16
Smoothness

• Best case (steady packet loss rate) TFRC is
  perfectly smooth, TCP exhibits sawtooth pattern
• TFRC performs well under mildly bursty conditions
  (3 rapid loss events followed by 3 slow 6
  events, fits within TFRC(6) history)
• In this rosy scenario, TFRC is not only smoother
  but gets better throughput

17
Awkwardness

• It is possible to find a burst pattern for any
  TFRC parameter that results in very bad
  perfomance - poor utilization and no smoothness
  just string together enough loss events to fill
  TFRC history window, then suddenly remove
  congestion
• How likely is this to occur naturally? Not sure.

18
Conclusions

• All of the proposed TCP-compatible alternatives
  appear safe (assuming this papers traffic model
  is reasonable). If anything, they may be too
  fair.
• Self-clocking is a useful fail-safe
• slowly-responsive protocols usually provide
  smooth bandwidth changes
• but not always

19
Open questions

• All traffic models were periodic with a fixed
  small number of flows. What happens when the
  number of flows varies?
• Most tests relied on RED queue management. How
  would they look under drop-tail (which is
  currently prevalent)?
• How does self-clocking affect TFRC smoothness
  (given that smoothness is TFRCs principal
  advantage)?
• Is smoothness at the granularity of a round trip
  particularly useful?