Vegas is a new implementation of TCP that achieves between 40 and 70 % better throughput, with one-fifth to onehalf the losses, as compared to the implementation of TCP in the Reno distributionof 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. 1

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.

This paper uses simulations to explore the benefits of adding selective acknowledgments (SACK) and selective repeat to TCP. We compare Tahoe and Reno TCP, the two most common reference implementations for TCP, with two modified versions of Reno TCP. The first version is New-Reno TCP, a modified version of TCP without SACK that avoids some of Reno TCP's performance problems when multiple packets are dropped from a window of data. The second version is SACK TCP, a conservative extension of Reno TCP modified to use the SACK option being proposed in the Internet Engineering Task Force (IETF). We describe the congestion control algorithms in our simulated implementation of SACK TCP and show that while selective acknowledgments are not required to solve Reno TCP's performance problems when multiple packets are dropped, the absence of selective acknowledgments does impose limits to TCP's ultimate performance. In particular, we show that without selective acknowledgments, TCP implementations are constrained to either retransmit at most one dropped packet per round-trip time, or to retransmit packets that might have already been successfully delivered. 1

The space communication environment and mobile and wireless communication environments show many similarities when observed from the perspective of a transport protocol. Both types of environments exhibit loss caused by data corruption and link outage, in addition to congestion-related loss. The constraints imposed by the two environments are also similar --- power, weight, and physical volume of equipment are scarce resources. Finally, it is not uncommon for communication channel data rates to be severely limited and highly asymmetric. We are working on solutions to these types of problems for space communication environments, and we believe that these solutions may be applicable to the mobile and wireless community. As part of our work, we have defined and implemented the Space Communications Protocol Standards-Transport Protocol (SCPSTP) , a set of extensions to TCP that address the problems that we have identified. The results of our performance tests, both in the laboratory and on actual satellites, indicate that the SCPS-TP extensions yield significant improvements in throughput over unmodified TCP on error-prone links. Additionally, the SCPS modifications significantly improve performance over links with highly asymmetric data rates.

In this paper, we propose a Quality of Service (QoS) architecture, QUANTA, for an end system protocol suite. We use TCP(UDP)/IP over ATM as a testbed to develop the architecture. We measure the application-level QoS in terms of throughput, delay, round trip time, and loss to identify the base-line performance an application can expect from such an environment. From the no-load condition we measure the behavior of these protocols at various data rates and user submitted data block sizes. We demonstrate the trade-offs involved in obtaining high throughput, low delays, low round trip time, and zero losses at different data rates. We use host-load condition experiments to understand the interaction between the CPU-intensive jobs and the communication-intensive jobs. We use network-load condition experiments to observe interaction between multiple streams of the above two protocol-suites, and its effect on the application QoS. Given these observations we define the missing components in the...

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 11 CHAPTER 1: Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12 1.1 Computer Networks : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12 1.2 Congestion : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 15 1.3 Protocols : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 17 1.4 Dissertation Outline : : : : : : : : : : : : : : : : : : : : : : : : : : : 18 CHAPTER 2: Simulator and Visualization Tools : : : : : : : : : : : : : : : : 20 2.1 The x-Kernel : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 20 2.1.1 Protocol Objects : : : : : : : : : : : : : : : : : : : : : : : : 22 2.1.2 Session Objects : : : : : : : : : : : : : : : : : : : : : : : : : 23 2.1.3 Message Objects : : : : : : : : : : : : : : : : : : : : : : : : : 24 2.1.4 Support Routines : : : : : : : : : : : : : : : : : : : : : : : : 24 2.1.5 x-Kernel Modifications to Support the Simulato...

this paper. Another approach may be to re-consider the congestion control mechanism of TCP to be suitably applied to the ABR service class. One example seems to be the Slow Start algorithm