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

• Sally Floyd, Kevin Fall in Proceedings of
  IEEE/ACM Transactions on Networking, 1999
• A Summary by Ashish Samant
• CS577 Spring 2005

2
Outline

• Need for end-to-end congestion control
• Unfairness, Congestion Collapse
• Per flow based scheduling Vs Congestion Control
  mechanisms at the router
• Identifying candidate flows for regulation
• Other incentives for flows

3
Introduction

• End hosts/applications may not use end-to-end
  congestion control schemes.
• Problem - This may lead to congestion collapse
  and unfairness, in times of congestion.
• Solution Isolate ill-behaving flows, use
  per-flow based queuing at routers.
• This may not be sufficient !!

4
Introduction . continued

• Authors suggest -
• Routers must support congestion control and
  regulate high-bandwidth flows.
• Routers must regulate best effort flows that
• are TCP-Unfriendly,
• unresponsive to congestion,
• use disproportionate bandwidth.

5
Introduction . continued

• Unresponsive flows cause two problems
• - Unfairness well-behaved flows may suffer
  bandwidth starvation because unresponsive flows
  do not react to congestion.
• - Congestion collapse the scarce bandwidth
  of the network is consumed by packets from
  unresponsive flows, that will be discarded
  sooner or later.

6
Experimental Setup
7
Unfairness 3 TCP, 1 UDP flow, FCFS
8
Fairness 3 TCP, 1 UDP flow, WRR
9
Congestion Collapse 3 TCP, 1 UDP flow, FCFS
10
Congestion Control 3 TCP, 1 UDP flow, WRR
11
Congestion Control 3 UDP, 1 TCP flow, WRR
12
Identifying non TCP-Friendly Flows

• TCP Friendly Flow arrival rate does not exceed
  that of any other TCP conformant flow.
• Maximum sending rate for a TCP Friendly flow
• T - sending rate p - packet drop rate B
  max packet size R minimum RTT
• Actual rates will be less than T.

13
Identifying non TCP-Friendly Flows

• Limitations
• Inconsistencies in finding packet size, round
  trip time.
• Measurements should be taken over a long
  interval of time.
• Bursty packet drops.
• Router Response
• Routers should freely restrict the bandwidth of
  non
• TCP Friendly flows.

14
Identifying Unresponsive Flows

• TCP Friendly test cannot be used at routers that
  are unable to determine packet sizes and RTTs.
• If packet drop rates increase by x , the arrival
  rate should drop by vx .
• When packet drop is constant, no flow will be
  identified as unresponsive.

15
Identifying Unresponsive Flows

• Limitations
• Packet drop may be because of various reasons,
  hard for flows with variable demand.
• Flows might be tempted to start with a higher
  initial bandwidth demand.
• Response
• Actively regulate the bandwidth of unresponsive
  flows in times of congestion.

16
Identifying flows using disproportionate flows

• Flows that require larger bandwidth than other
  flows that reduce their demand.
• These might be TCP friendly but still be
  disproportionate.
• Arrival rate lt log(3n) / n n no of flows
• Arrival rate lt c / vp p pkt drop rate
• c some constant

17
Comments and Conclusion

• Alternate approaches
• - use schemes that are a mix of FCFS and
  per-flow based approach ( FCFS scheduling with
  differential dropping ).
• - pricing incentives.
• granularity of flows
• - apply fairness tests to single/aggregate of
  flows.
• min-max fairness measure
• - need to look at the entire path, all the
  congested links.

18
Comments and Conclusion continued

• Breaking a TCP connection, increased local
  throughput but also increases global packet drop
  rate.

19
Derivation of TCP Friendly Rate

• Once congestionWindow gt W a packet is dropped
  and the congestion window is halved.
• As long as congestionWindow lt W window is
  increased by 1, per RTT
• W/2 (W/21) (W/22) W 3/8W2
• gt per packet drop max 3/8W2 packets are
  sent
• gt max packet drops lt 1/(3/8W2)

20
Derivation of TCP Friendly Rate Continued

• Max bytes transferred per cycle of steady state
• Total packets sent Avg. packet Size
• Avg Round Trip Time
• ( Total packets sent 0.75W )
• gt (0.75 W B) / R
• gt