TCP Window Research Articles

Optimization of wide-area ATM and local-area ethernet/FDDI network configurations for high-speed telemedicine communications employing NASA's ACTS.

A high data rate terrestrial and satellite network was implemented to transfer medical images and data. This article describes the a optimization of the workstations and switching equipment incorporated into the network. Topics discussed in this article include tuning of the network software, the configuration of the Sun Microsystems workstations, the FORE Systems asynchronous transfer mode switches, as well as the throughput results of two telemedicine experiments undertaken by Mayo's physician staff. The technical staff was successful in achieving the data throughput needed by the telemedicine software; particularly important was the proper determination of peak throughput and TCP window sizes to ensure optimum use of the resources available on the Sun Microsystems and Hewlett Packard workstations.

Issues in improving TCP performance over ATM

We consider the adequacy of TCP control mechanisms for rate- based ATM service classes in general. TCP congestion control and avoidance algorithms are discussed. We study their match to the ATM variable bit rate (VBR) service class. We explain that by using TCP rather than VBR policing we introduce an under-utilization in the network channel capacity. We propose some enhancements and fine tunings to the rate-based classes, present a new TCP window control mechanism and show an improvement in the effective bandwidth used.

An empirical study of TCP/IP performance over ATM

This paper outlines some basic performance characteristics of the Transmission Control Protocol/Internet Protocol (TCP/IP) over Asynchronous Transfer Mode (ATM). It also discusses a few solutions to assure acceptable TCP/IP performance over ATM which are implemented by the industry during the last couple of years. The conclusions in this paper are based on empirical TCP/IP performance test results collected on a DS3 ATM research testbed, architected with commercially available IP and ATM equipment 2 This paper does not endorse any specific equipment. Tests were performed with available equipment in the lab. 2 . TCP/IP performance can vary widely and suffer significantly over ATM networks with large bandwidth*delay products. First, it is essential that the TCP window size matches the bandwidth*delay product of the end-to-end connection to fully utilize the bandwidth provided by the broadband network. Even if the window size meets this criteria, TCP performance can still be unacceptable, especially if the buffering within the ATM network is limited. A single limited-buffer bottleneck is sufficient to degrade the performance of a TCP connection when multiple traffic sources congest the bottleneck resource, such as in ATM networks with small buffer switches. One approach to assure acceptable TCP/IP performance is to limit the data rate into the bottleneck resource by exercising rate control at the entry to the ATM network. A better solution is to provide sufficient buffering within the ATM network.

Two-way TCP traffic over rate controlled channels: effects and analysis

We study the performance of bidirectional TCP/IP connections over a network that uses rate-based flow and congestion control. An example of such a network is an asynchronous transfer mode (ATM) network using the available bit rate (ABR) service. The sharing of a common buffer by TCP packets and acknowledgment (acks) has been known to result in an effect called ack compression, where acks of a connection arrive at the source bunched together, resulting in unfairness and degraded throughput. It has been the expectation that maintaining a smooth flow of data using rate-based flow control would mitigate, if not eliminate, the various forms of burstiness experienced with the TCP window flow control. However, we show that the problem of TCP ack compression appears even while operating over a rate-controlled channel. The degradation in throughput due to bidirectional traffic can be significant. For example, even in the simple case of symmetrical connections with adequate window sizes, the throughput of each connection is only 66.67% of that under one-way traffic. By analyzing the periodic bursty behavior of the source IP queue, we derive estimates for the maximum queue size and arrive at a simple predictor for the degraded throughput, for relatively general situations. We validate our analysis using simulation on an ATM network using the explicit rate option of the ABR service. The analysis predicts the behavior of the queue and the throughput degradation in simple configurations and in more general situations.

Connections with multiple congested gateways in packet-switched networks part 1

In this paper we explore the bias in TCP/IP networks against connections with multiple congested gateways. We consider the interaction between the bias against connections with multiple congested gateways, the bias of the TCP window modification algorithm against connections with longer roundtrip times, and the bias of Drop Tail and Random Drop gateways against bursty traffic. Using simulations and a heuristic analysis, we show that in a network with the window modification algorithm in 4.3 tahoe BSD TCP and with Random Drop or Drop Tail gateways, a longer connection with multiple congested gateways can receive unacceptably low throughput. We show that in a network with no bias against connections with longer roundtrip times and with no bias against bursty traffic, a connection with multiple congested gateways can receive an acceptable level of throughput.We discuss the application of several current measures of fairness to networks with multiple congested gateways, and show that different measures of fairness have quite different implications. One view is that each connection should receive the same throughput in bytes/second, regardless of roundtrip times or numbers of congested gateways. Another view is that each connection should receive the same share of the network's scarce congested resources. In general, we believe that the fairness criteria for connections with multiple congested gateways requires further consideration.

Traffic phase effects in packet-switched gateways

Much of the traffic in existing packet networks is highly periodic, either because of periodic sources (e.g., real time speech or video, rate control) or because window flow control protocols have a periodic cycle equal to the connection roundtrip time (e.g., a network-bandwidth limited TCP bulk data transfer). Control theory suggests that this periodicity can resonate (i.e., have a strong, non-linear interaction) with deterministic estimation or control algorithms in network gateways. 1 In this paper we define the notion of traffic phase in a packet-switched network and describe how phase differences between competing traffic streams can be the dominant factor in relative throughput. Drop Tail gateways in a TCP/IP network with strongly periodic traffic can result in systematic discrimination against some connections. We demonstrate this behavior with both simulations and theoretical analysis. This discrimination can be eliminated with the addition of appropriate randomization to the network. In particular, analysis suggests that simply coding a gateway to drop a random packet from its queue (rather than the tail) on overflow is often sufficient.We do not claim that Random Drop gateways solve all of the problems of Drop Tail gateways. Biases against bursty traffic and long roundtrip time connections are shared by both Drop Tail and Random Drop gateways. Correcting the bursty traffic bias has led us to investigate a different kind of randomized gateway algorithm that operates on the traffic stream, rather than on the queue. Preliminary results show that the Random Early Detection gateway, a newly developed gateway congestion avoidance algorithm, corrects this bias against bursty traffic. The roundtrip time bias (at least in TCP/IP networks) results from the TCP window increase algorithm, not from the gateway dropping policy, and we briefly discuss changes to the window increase algorithm that could eliminate this bias.