The incremental deployability of RTT-based congestion avoidance for high speed TCP Internet connections

  • Authors:
  • Jim Martin;Arne Nilsson;Injong Rhee

  • Affiliations:
  • GartnerGroup, 5000 Falls of Neuse Road, Raleigh, NC;ECE Department, North Carolina State University, Raleigh, NC;CS Department, North Carolina State University, Raleigh, NC

  • Venue:
  • Proceedings of the 2000 ACM SIGMETRICS international conference on Measurement and modeling of computer systems
  • Year:
  • 2000

Quantified Score

Hi-index 0.00

Visualization

Abstract

Our research focuses on end-to-end congestion avoidance algorithms that use round trip time (RTT) fluctuations as an indicator of the level of network congestion. The algorithms are referred to as delay-based congestion avoidance or DCA. Due to the economics associated with deploying change within an existing network, we are interested in an incrementally deployable enhancement to the TCP/Reno protocol. For instance, TCP/Vegas, a DCA algorithm, has been proposed as an incremental enhancement. Requiring relatively minor modifications to a TCP sender, TCP/Vegas has been shown to increase end-to-end TCP throughput primarily by avoiding packet loss. We study DCA in today's best effort Internet where IP switches are subject to thousands of TCP flows resulting in congestion with time scales that span orders of magnitude. Our results suggest that RTT-based congestion avoidance may not be reliably incrementally deployed in this environment. Through extensive measurement and simulation, we find that when TCP/DCA (i.e., a TCP/Reno sender that is extended with DCA) is deployed over a high speed Internet path, the flow generally experiences degraded throughput compared to an unmodified TCP/Reno flow. We show (1) that the congestion information contained in RTT samples is not sufficient to predict packet loss reliably and (2) that the congestion avoidance in response to delay increase has minimal impact on the congestion level over the path when the total DCA traffic at the bottleneck consumes less than 10% of the bottleneck bandwidth.