Promoting the Use of EndtoEnd Congestion Control

1
Promoting the Use of End-to-End Congestion
Control

• Tapan Karwa
• CS590F

2
What is Congestion Control

• Its a control problem.
• Its concerned with allocation of resources.
• The problem limited resources.
• Will infinite BW, buffer space and super fast
  processors help?
• CC is not a resource shortage problem.
• Congestion will occur. It needs to be handled.
  Dynamically.

3
Classical Congestion Collapse

• Congestion collapse occurs when the network is
  increasingly busy, but little useful work is
  getting done.
• Problem paths clogged with unnecessarily
  retransmitted packets.
• Reasons heterogeneity, dynamic network
  conditions, bad timers with Go-back-N
  retransmissions.
• Fix Modern TCP retransmit timer and congestion
  control algorithms. Based on the assumption that
  sources will cooperate.

4
Congestion Collapse from undelivered packets

• Problem Paths clogged with packets that are
  discarded before they reach the receiver.
• Reasons open-loop apps not performing
  end-to-end CC, best-effort apps increasing their
  sending rate on packet loss.
• Unresponsive flows. No cooperation. Router
  mechanisms (scheduling mechanisms, ECN) dont
  help either.
• Fix Either end-to-end CC, along with mechanisms
  to detect unresponsive flows, or virtual-circuit
  style of guarantee packet delivery.

5
Why do we need CC

• So that the application can better achieve its
  goals of minimizing loss and delay, maximizing
  throughput.
• Fairness. Especially with unresponsive flows
  around.

6
What is the fairness goal?

• No connection /session/end-node should hog the
  network resources.
• TCP is the dominant transport protocol in the
  Internet (90-95 of the bytes/packets).
• Routers are likely to use FIFO scheduling.
• New forms of traffic/new applications that
  compete with TCP as best-effort traffic in FIFO
  queues should not be significantly more (or less)
  aggressive than TCP.

7
Mechanisms within the network

• Mechanisms within the network infrastructure to
  restrict unresponsiveness during times of
  congestion.
• Max sending rate

8
Identifying TCP-unfriendly flows

• Given R and B, if the steady-state packet drop
  rate is x, then the arrival rate of the flow
  should be at most y.
• R is set to twice the propagation delay of the
  attached link.
• Limitations
• Difficult to determine B, R.
• Applies only to non-bursty packet drop behavior.
  During severe congestion, multiple packet drops
  are very likely.
• Measurements should be taken over large intervals
  in comparison to the RTT of the connection.

9
Identifying unresponsive flows

• To test if a high BW connection is responsive,
  check if, when the steady-state drop rate
  increases by factor x, does the arrival rate
  decrease by a factor close to squareroot(x).
• Can be applied to aggregated traffic too.
• Limitations
• Requires estimates of a flows arrival rate and
  packet drop rate over long time intervals.
• Flows could start with high initial BW and then
  reduce it. This means that just testing for
  unresponsiveness might not be enough.

10
Identifying flows with disproportionate BW

• Applied when a flow is consuming a larger share
  than other flows who could use more BW.
• Two components
• Check if flow is using more than its share.
• Check if flow has a high arrival rate, relative
  to the level of congestion, as reflected by the
  drop rate.
• Limitations
• Difficult to access how unsatisfied a flow is.

11
Other approaches and Conclusion

• Instead of using the mechanisms proposed, we
  could use per-flow scheduling.
• Limitations difficult to implement, FCFS is
  more optimal.
• End-to-end congestion control is required for
  reasonable usage of the Internet.
• Mechanisms to punish non-responsive flows are
  also required to prevent pathological situations.