This paper presents Random Early Detection (RED) gate-ways for congestion avoidance in packet-switched networks. The gateway detects incipient congestion by com-puting the average queue size. The gateway could notify connections of congestion either by dropping packets ar-riving at the gateway or by setting a bit in packet headers. When the average queue size exceeds a preset threshold,the gateway drops or marks each arriving packet with a certain probability, where the exact probability is a func-tion of the average queue size. RED gateways keep the average queue size low while allowing occasional bursts of packets in the queue. During congestion, the probability that the gateway notifies a particular connection to reduce its window is roughly proportional to that connection's share of the bandwidth throughthe gateway. RED gateways are designed to accompany a transport-layer congestion control protocol such as TCP.The RED gateway has no bias against bursty traffic and avoids the global synchronization of many connectionsdecreasing their window at the same time. Simulations of a TCP/IP network are used to illustrate the performance of RED gateways.

This paper discusses the use of Explicit Congestion Notification (ECN) mechanisms in the TCP/IP protocol. The first part proposes new guidelines for TCP’s response to ECN mechanisms (e.g., Source Quench packets, ECN fields in packet headers). Next, using simulations, we explore the benefits and drawbacks of ECN in TCP/IP networks. Our simulations use RED gateways modified to set an ECN bit in the IP packet header as an indication of congestion, with Reno-style TCP modified to respond to ECN as well as to packet drops as indications of congestion. The simulations show that one advantage of ECN mechanisms is in avoiding unnecessary packet drops, and therefore avoiding unnecessary delay for packets from low-bandwidth delay-sensitive TCP connections. A second advantage of ECN mechanisms is in networks (generally LANs) where the effectiveness of TCP retransmit timers is limited by the coarse granularity of the TCP clock. The paper also discusses some implementation issues concerning specific ECN mechanisms in TCP/IP networks.

Vegas is an implementation of TCP that achieves between 37 and 71 % better throughput on the Internet, with one-fifth to one-half the losses, as compared to the implementation of TCP in the Reno distribution of BSD Unix. This paper motivates and describes the three key techniques employed by Vegas, and presents the results of a comprehensive experimental performance study—using both simulations and measurements on the Internet—of the Vegas and Reno implementations of TCP.

Abstract not found

This paper explores the claims that TCP Vegas [2] both uses network bandwidth more efficiently and achieves higher network throughput than TCP Reno [6]. It explores how link bandwidth, network buffer capacity, TCP receiver acknowledgment algorithm, and degree of network congestion affect the relative performance of Vegas and Reno. 1 Introduction Jacobson released his TCP slow-start flow control algorithm [5] in the Tahoe distribution of bsd unix and revised it two years later for the Reno distribution [6]. Since then, researchers have implemented the RFC 1323 extensions -- bigger TCP windows and time-stamped based rtt exchange -- to improve TCP performance over high bandwidth connections. The RFC 1323 extensions do not, however, implement congestion avoidance. Last year, Brakmo, O'Malley and Peterson [2] claimed that their sender-side congestion avoidance algorithm, dubbed TCP Vegas, yielded 40-70% better throughput while retransmitting 2-5 times fewer segments than TCP Reno, both in...

TCP is a popular transport protocol used in present-day internet. When packet losses occur, TCP assumes that the packet losses are due to congestion, and responds by reducing its congestion window. When a TCP connection traverses a wireless link, a significant fraction of packet losses may occur due to transmission errors. TCP responds to such losses also by reducing congestion window. This results in unnecessary degradation in TCP performance. We define a class of functions named loss predictors which may be used by a TCP sender to guess the actual cause of a packet loss (congestion or transmission error) and take appropriate actions. These loss predictors use simple statistics on round-trip times and/or throughput, to determine the cause of a packet loss. We investigate their ability to determine the cause of a packet loss. Unfortunately, our simulation measurements suggest that the three loss predictors do not perform too well. 1. Introduction TCP is a popular protocol for reliabl...

Abstract—We study the performance of TCP in an internetwork consisting of both rate-controlled and nonrate-controlled segments. A common example of such an environment occurs when the end systems are part of IP datagram networks interconnected by a rate-controlled segment, such as an ATM network using the available bit rate (ABR) service. In the absence of congestive losses in either segment, TCP keeps increasing its window to its maximum size. Mismatch between the TCP window and the bandwidth-delay product of the network will result in accumulation of large queues and possibly buffer overflows in the devices at the edges of the rate-controlled segment, causing degraded throughput and unfairness. We develop an explicit feedback scheme, called Explicit Window Adaptation, based on modifying the receiver’s advertised window in TCP acknowledgments returning to the source. The window size indicated to TCP is a function of the free buffer in the edge device. Results from simulations with a wide range of traffic scenarios show that this explicit window adaptation scheme can control the buffer occupancy efficiently at the edge device, and results in significant improvements in packet loss rate, fairness, and throughput over a packet discard policy such as Random Early Detection (RED). Index Terms—Buffer management, congestion control, explicit window adaptation, TCP. I.

We present a new implementation of TCP that is better suited to today's Internet than TCP Reno or Tahoe. Our implementation of TCP, which we call TCP Santa Cruz, is designed to work with path asymmetries, out-of-order packet delivery, and networks with lossy links, limited bandwidth and dynamic changes in delay. The new congestion-control and error-recovery mechanisms in TCP Santa Cruz are based on: using estimates of delay along the forward path, rather than the round-trip delay; reaching a target operating point for the number of packets in the bottleneck of the connection, without congesting the network; and making resilient use of any acknowledgments received over a window, rather than increasing the congestion window by counting the number of returned acknowledgments. We compare TCP Santa Cruz with the Reno and Vegas implementations using the ns2 simulator. The simulation experiments show that TCP Santa Cruz achieves significantly higher throughput, smaller delays, and smaller del...

The congestion control algorithm embedded in the 4.3-Tahoe BSD TCP implementation has dramatically improved congestion control over the Internet. However, several recent simulation studies on the dynamics of this algorithm has revealed that the algorithm exhibits clear oscillatory patterns in sending window size, round trip delay and bottleneck queue length. In this paper, we present a new congestion signal scheme and a dual traffic adjustment strategy. Simulation results show that our modifications can eliminate the periodic packet losses and substantially reduce the traffic oscillation.

Wireless access networks in the form of wireless local area networks, home networks, and cellular networks are becoming an integral part of the Internet. Unlike wired networks, random packet loss due to bit errors is not negligible in wireless networks, and this causes significant performance degradation of transmission control protocol (TCP). We propose and study a novel end-to-end congestion control mechanism called TCP Veno that is simple and effective for dealing with random packet loss. A key ingredient of Veno is that it monitors the network congestion level and uses that information to decide whether packet losses are likely to be due to congestion or random bit errors. Specifically: 1) it refines the multiplicative decrease algorithm of TCP Reno---the most widely deployed TCP version in practice---by adjusting the slow-start threshold according to the perceived network congestion level rather than a fixed drop factor and 2) it refines the linear increase algorithm so that the connection can stay longer in an operating region in which the network bandwidth is fully utilized. Based on extensive network testbed experiments and live Internet measurements, we show that Veno can achieve significant throughput improvements without adversely affecting other concurrent TCP connections, including other concurrent Reno connections. In typical wireless access networks with 1% random packet loss rate, throughput improvement of up to 80% can be demonstrated. A salient feature of Veno is that it modifies only the sender-side protocol of Reno without changing the receiver-side protocol stack.