A New Scheme for TCP Congestion Control: Smooth-Start and Dynamic Recovery Haining Wang Carey Williamson Department of Computer Science University of Saskatchewan Saskatoon, SK, Canada E-mail:
[email protected],
[email protected]
Abstract
as well as more recent additions such as Fast Retransmit and Fast Recovery [6, 11, 12].
This paper presents a new approach to TCP congestion control. The new scheme includes two parts: (1) the Smooth-Start algorithm, which replaces the Slow-Start algorithm at the start of a TCP connection or after a retransmission timeout, and (2) the Dynamic Recovery algorithm, which replaces the Fast Recovery algorithm to recover packet losses when a TCP connection is congested. Both algorithms require modifications only to the sender side of the TCP implementation. Simulation is used to evaluate the performance of the algorithms. The simulation experiments are conducted using the ns simulator, to facilitate comparisons with Tahoe, Reno, New-Reno, SACK, and FACK TCP. The simulation results show that the new scheme performs at least as well as SACK and FACK TCP, which in turn consistently outperform TCP Tahoe and Reno. Furthermore, the implementation of the new scheme is simpler than that of SACK and FACK.
At present, there are two remaining problems in TCP congestion control that can degrade the performance of TCP connections. One problem is in the Slow-Start algorithm; the other is in the Fast Recovery algorithm. In the Slow-Start algorithm, since a TCP sender has no knowledge of network capacity at the beginning of transmission, the sender often uses default values for parameters such as ssthresh, the Slow-Start threshold [10]. In many cases, this results in the sender transmitting too many packets too quickly, causing multiple packet losses from a window of data [9]. These losses in turn lead to the second problem. In the Fast Recovery algorithm, when multiple packets are lost from the same window of data, the TCP sender often incurs a retransmission timeout, and substantial TCP performance degradation [6]. These two problems are particularly acute for Web-based document transfers, which are often so short-lived (e.g., 4-20 Kilobytes [2]) that the TCP connection never reaches “steady-state” before it terminates.
1. Introduction With the rapid growth of the Internet and the widespread use of the TCP/IP protocol suite [20], the TCP congestion control algorithm [10] has become a key factor influencing the performance and behaviour of the Internet [17, 18]. Though well studied in the literature [1, 4, 5, 7, 8, 9, 15, 17, 21, 22], improving the performance of TCP congestion control is important as the Internet continues to grow in size and scope, since TCP is the underlying reliable data transfer protocol for many network applications, including electronic mail, file transfer, and the World-Wide Web. The congestion avoidance and control mechanisms in TCP have evolved significantly in the last ten years. Current implementations of TCP include Jacobson’s classical SlowStart algorithm for congestion avoidance and control [10],
To resolve these problems, several new TCP congestion control mechanisms have been proposed. These include TCP Vegas [3], SACK and FACK TCP [13, 14], improved initial estimates for ssthresh [9], and better congestion recovery algorithms [9]. However, handling multiple packet losses from a window of data still proves to be a challenge for many TCP implementations (e.g., Tahoe, Reno). While SACK and FACK TCP can handle multiple packet losses better [4, 13], they add significant complexity to the TCP implementation, both at the sender and the receiver. In this paper, we propose two new algorithms, called Smooth-Start and Dynamic Recovery, to solve the problems in TCP congestion control. The Smooth-Start algorithm is intended to replace the Slow-Start algorithm, which is invoked at the start of a TCP connection, or after a retransmission timeout. The Dynamic Recovery algorithm is intended to replace the Fast Recovery algorithm, which recovers lost
packets when a TCP connection is congested. In addition to packet recovery, the other goal of the Dynamic Recovery algorithm is to probe the new equilibrium of a TCP connection during the recovery period. The changes required by the two algorithms are only at the sender side of TCP. No modifications are needed at the receiver side. The purpose of this paper is to demonstrate the performance advantages of these two new algorithms, using simulation. The simulation experiments are conducted using the ns simulator, developed at Lawrence Berkeley National Laboratories (LBNL). Use of this simulator facilitates comparisons with other TCP congestion control algorithms, such as those in Tahoe, Reno, New-Reno, SACK, and FACK TCP. The simulation results show that the new scheme compares favourably with SACK and FACK in terms of the performance improvements achieved. Furthermore, since there is no requirement for selective acknowledgements or receiver modifications in our scheme, its implementation is actually much simpler than that of SACK and FACK TCP. The remainder of this paper is organized as follows. Section 2 provides some background on TCP congestion control. Section 3 presents a description of the Smooth-Start algorithm and its simulation results. Section 4 describes the Dynamic Recovery algorithm, and shows its simulation results. Finally, Section 5 concludes the paper.
2. Background: TCP congestion control Van Jacobson’s 1988 paper [10] laid the cornerstone for TCP congestion control research. In his seminal paper, Jacobson proposed an important principle called Packet Conservation, which means that a new packet is not injected into the network until an old packet leaves the network. Note, however, that the Packet Conservation principle is only applied when the TCP connection is in equilibrium, with a full window of data in transit on the network (i.e., the “pipeline” is nearly fully loaded). At the beginning of transmission or after a retransmission timeout, the pipeline is empty. Therefore, the sender does not obey the Packet Conservation principle. Instead, senders employ the SlowStart algorithm, which transmits two new data packets for every received ACK, to quickly fill the empty pipeline and bring the connection toward its equilibrium. Once in equilibrium, the sender enters a congestion avoidance phase that more closely obeys the Packet Conservation principle. The key mechanism that follows from the Packet Conservation principle is Self-clocking: the sender uses returning ACKs as a “clock” to determine when to send new packets into the network. TCP’s Self-clocking is a crucial mechanism that keeps the data flowing on a TCP connection and protects the connection from congestion. The loss of packets is not a real problem for a TCP connection: it just indicates the occurrence of congestion in the network. However, the
loss of Self-clocking is a serious problem, since it causes the pipeline to empty. If the pipeline empties, the TCP sender has to spend several round-trip times to fill the pipeline and restore the Self-clocking. In other words, the loss of Selfclocking severely degrades TCP’s performance, and must be avoided if at all possible. All TCP congestion control schemes, including our new scheme, are based on the Packet Conservation principle and the derived mechanism of Self-clocking. A good TCP congestion control scheme should maintain Self-clocking and achieve high network utilization even if the available resources in the network change dramatically over time.
3. Smooth-Start 3.1. Motivation The fundamental problem in the Slow-Start algorithm is that the congestion window size increases too quickly as the connection nears its target equilibrium, leading to multiple losses of packets from a window of data. In the Slow-Start algorithm, each ACK for new data increases the congestion window size by one segment, doubling the congestion window size every round-trip time (see Figure 1). At the beginning of the transmission, the exponential increase of the congestion window size is necessary to fill the empty pipeline quickly. However, as the congestion window size approaches the equilibrium of the connection (unfortunately, the sender is not aware of this until packet loss occurs), this doubling is too aggressive: it can make the congestion window size at the next round-trip time far larger than the actual bandwidth-delay product, and cause multiple lost packets.
3.2. The Smooth-Start algorithm Our new scheme, called Smooth-Start, proposes a more graceful rampup of congestion window size in the SlowStart phase, so that multiple packet losses are much less likely to occur. The intuitive idea behind our algorithm is shown in Figure 2. In Smooth-Start, we use ssthresh/2 as a separator1 to divide the old Slow-Start phase into two subphases. If the congestion window size is less than ssthresh/2, the sender is in the first subphase, called the filling phase. In this subphase, Smooth-Start behaves the same as Slow-Start: the congestion window size increases by one segment for each received ACK. Beyond ssthresh/2, the sender is the second subphase, called the probing phase. In this subphase, the congestion window size increases more slowly (i.e., only upon the receipt of multiple ACKs). 1 Other separator values, such as ssthresh/4 and ssthresh/8, could also be used.
Window Size
Window Size
ssthresh
ssthresh
ssthresh/2
ssthresh/2
0
Time
Figure 1. Illustration of the Slow-Start algorithm: The congestion window size grows exponentially in the Slow-Start phase (up to ssthresh), and then grows linearly in the congestion avoidance phase.
The number of round-trip times required to increase the congestion window size from ssthresh/2 to ssthresh depends upon the gradient chosen for the Smooth-Start algorithm. For example, consider the following scenario. If in the first round-trip time, two ACKs trigger one increment of the congestion window size, and in the second round-trip time, three ACKs trigger one increment of the congestion window size, then a total of two round-trip times are needed to increase the congestion window size from ssthresh/2 to ssthresh. The detailed calculation is shown below, with cwnd representing the congestion window size: After one round-trip time of the second subphase:
cwnd =
ssthresh 2
+
1 2
3ssthresh ssthresh = 2 4
0
Time
Figure 2. Illustration of the Smooth-Start algorithm: The congestion window size grows exponentially in the filling phase (up to ssthresh=2), slower than exponentially in the probing phase, and then linearly in the congestion avoidance phase.
estimate, if any, of the bandwidth-delay product2 of the connection. In our preliminary experiments (not shown here), we have found the value N = 2 to provide reasonable and robust performance.
3.3. Simulation setup We tested the Smooth-Start algorithm by implementing it in the ns network simulator [16]. The simulator includes models of Tahoe, Reno, New-Reno, SACK, and FACK TCP, which all employ the Slow-Start algorithm. We replaced the Slow-Start in those TCP models with Smooth-Start. S1
After two round-trip times of the second subphase: cwnd =
3ssthresh 4
+
1 3
3ssthresh 4
=
8Mbps 5ms
R1
ssthresh
In general, if we start with N ACKs triggering an increment of the congestion window size for the first round-trip time, and (N + i) ACKs triggering an increment of the congestion window size for the ith subsequent round-trip time, then a total of N round-trip times are needed to increase the congestion window size from ssthresh/2 to ssthresh. Here, the number N controls the gradient. As an analogy, think of N as controlling the “accelerator pedal”, and determining how quickly you “ease off” as you approach the desired “target velocity”. Choosing a suitable value for N requires a tradeoff between the probe time and probe granularity. This choice depends to some extent on the level of confidence in the
0.8Mbps 100ms
K1
8Mbps 5ms
S2
Figure 3. Simulation topology used for Smooth-Start experiments.
The simulation topology used is shown in Figure 3. This topology is the same as that used by Fall and Floyd [4]. In 2 It is important to note that the Smooth-Start scheme does not rely on
the ssthresh estimator proposed by Hoe [9]. While Smooth-Start can work better with a good ssthresh estimator, Smooth-Start can work well even without an ssthresh estimator.
Slow-start: Tahoe with ssthresh=14
Smooth-start: Tahoe with ssthresh=14
packet
packet packets skip-1 skip-2 drops
1.0000 0.9500 0.9000
0.9500 0.9000
0.8500
0.8500
0.8000
0.8000
0.7500
0.7500
0.7000
0.7000
0.6500
0.6500
0.6000
0.6000
0.5500
0.5500
0.5000
0.5000
0.4500
0.4500
0.4000
0.4000
0.3500
0.3500
0.3000
0.3000
0.2500
0.2500
0.2000
0.2000
0.1500
0.1500
0.1000
0.1000
0.0500
packets skip-1 skip-2
1.0000
0.0500
0.0000
0.0000
-0.0500
time 0.0000
1.0000
2.0000
3.0000
4.0000
5.0000
-0.0500
time 0.0000
1.0000
2.0000
(a)
3.0000
4.0000
5.0000
(b)
Figure 4. Simulation results for TCP Tahoe: (a) Slow-Start; (b) Smooth-Start. Figure 3, R1 represents a finite-buffer drop-tail router. S1 and S2 represent sending hosts. The links are labeled with their bandwidth and one-way propagation delay. This network has a delay-bandwidth product of 21 packets, assuming 1024-byte packets. A drop-tail router with small buffers is used, since this scenario is intended to be a simple scenario for illustrating TCP’s congestion control algorithms. Only one TCP connection from S1 to K1 is used in these initial simulations. The type of data traffic in our simulation is FTP (i.e., bulk data transfer). The data receiver sends an ACK for every data packet received (i.e., delayed ACKs are disabled).
3.4. Simulation results We tested the performance improvements achieved by replacing Slow-Start with Smooth-Start in TCP Tahoe, Reno and SACK. Figure 4 shows the results for TCP Tahoe. Results for other TCPs are similar, and are not shown here. Simulation results are presented using the standard technique of TCP sequence number plots [4]. The graphs were generated by tracing packets entering and departing router R1. For each figure, the x-axis represents the packet arrival or departure time in seconds. The y-axis represents the packet sequence number mod 90, normalized to 1.0. Packets are numbered starting with packet 0. Each packet arrival and departure is indicated by a square on the figure. Desirable TCP behaviour is reflected by steep upward-sloping lines with a constant slope, illustrating steady throughput at the full bottleneck capacity. Figure 4 clearly shows the performance improvements possible with the Smooth-Start algorithm. In this set of graphs, the Smooth-Start algorithm shows fewer packet losses, fewer timeouts, and consistently higher throughput than the Slow-Start algorithm. The number of TCP data
packets successfully delivered in the same amount of simulation time is 25-100% higher for Smooth-Start than for Slow-Start, depending on the version of TCP that is used. We have also found the Smooth-Start algorithm to be relatively robust even with poor initial estimates for ssthresh (not shown here, due to space limitations).
4. Dynamic Recovery The previous section introduced the Smooth-Start component of our new TCP congestion control scheme, which improves the startup dynamics of TCP, and reduces the chance of multiple packet losses. However, multiple packet losses can still occur, in some scenarios. We now introduce the second component of our congestion control scheme: an improved mechanism for recovery from multiple packet losses.
4.1. Overview Our new congestion recovery algorithm is called Dynamic Recovery, because the threshold value that determines the end of the congestion recovery period is dynamic, not static. That is, the threshold value varies with the number of packet losses. By contrast, the schemes proposed by Hoe [9] and by Mathis and Mahdavi [13] use a fixed threshold value to indicate the end of the recovery phase, regardless of how many packets are lost from a window of data. This threshold is the value of the TCP sender state variable snd.nxt (i.e., the sequence number of the first byte of unsent data [19]) at the time that the first packet loss was detected. The recovery phase ends as soon as snd.una (i.e., the sequence number of the first byte of unacknowledged data) advances to or beyond this threshold.
In the Dynamic Recovery algorithm, the threshold value used to detect the end of the recovery phase advances if there are further packet losses detected during the recovery phase. In particular, the threshold is set dynamically to the value of snd.nxt at the time the most recent packet loss was detected. The recovery phase ends when snd.una advances to or beyond this threshold, which may be significantly different from the value of snd.nxt at the time the first packet loss was detected. Furthermore, in the Dynamic Recovery algorithm, the sender continues to send out new data packets per roundtrip time even during the congestion recovery period. Thus a sender not only recovers from packet losses, but also probes the new equilibrium of the connection during the congestion recovery period. The following subsections provide further details on the Dynamic Recovery algorithm.
4.2. Preamble: The active number The key to the dynamic recovery algorithm is knowing the number of “active” data packets flowing on a connection, and not just the number of outstanding (i.e., unacknowledged) packets on a connection. In this discussion, we assume that the TCP sender has just detected a congestion event (i.e., packet loss), done a Fast Retransmit, and entered the congestion recovery phase. In the congestion recovery phase, the outstanding packets of the connection can be divided into three groups: active, inactive and dropped. The active group is the set of data packets that are in transit, which may include retransmitted packets and packets that might be lost at the network bottleneck. The inactive group is the set of data packets that were transmitted during the past round-trip times and have already arrived at the receiver, but have not yet been acknowledged3. The dropped group is the set of data packets that were lost during the past round-trip times. Needless to say, the outstanding packets as a whole do not represent the data packets in the pipeline any more. Only the active group represent the data packets in the pipeline. Therefore, the congestion window cwnd is no longer adequate for congestion control in the congestion recovery period. A new state variable actnum is thus introduced to indicate the number of active data packets in the pipeline during a round-trip time. At the end of the first roundtrip time of the congestion recovery period, actnum replaces cwnd as the means to provide flow control at the sender side. Once the congestion recovery period ends, flow control responsibilities are returned to cwnd. 3 In fact, each of these packets has caused the receiver to send a duplicate acknowledgement to the sender,since these packets have sequence numbers larger than the sequence number(s) of the lost packet(s).
Further Packet Loss
Entrance
Damping Phase
Probe Phase
Exit
Figure 5. Structure of Dynamic Recovery. Upon receiving 3 dup ACKs enter the Congestion Recovery phase Entrance: 1. recover_ = maxseq_; 2. ssthresh_ = win * 2/ 3; 3. retransmission; 4. last_recover = recover_; dup ACKs > 3
actnum is still maintained as 0
Damping Phase: Upon receiving 3 dup ACKs send out Further Packet Loss: 1. reset ssthresh as actnum * 2/3; 2. reset actnum as 0. 3. update last_recover_
Partial ACK, and seqno_ > last_recover_; indicate further packet loss
2 new data packet beyond maxseq_.
Partial ACK arrived
Set actnum as 2/3 * dupwnd
Probe Phase: Upon receiving a dup ACK send out a new data packets beyond maxseq_.
New ACK arrived (i.e. seqno_ > recover_)
Partial ACK, and seqno_< last_recover_
Exit: 1. dupwnd = 0; 2. cwnd = actnum; 3. actnum = 0.
Figure 6. The Dynamic Recovery algorithm.
4.3. The Dynamic Recovery algorithm To better describe the Dynamic Recovery algorithm, we divide it into two subphases. Figure 5 shows the high-level structure of the algorithm. A more formal description of the Dynamic Recovery algorithm is shown in Figure 6. The latter description refers to several ns simulator state variables, which are explained in Table 1. Note that last recover is the only new state variable required by our algorithm. As with Fast Recovery, Dynamic Recovery is triggered by Fast Retransmit. However, in the Dynamic Recovery algorithm, cwnd is not immediately halved. Instead, cwnd remains unchanged until the end of the recovery phase, since it is not used for congestion control in Dynamic Recovery. At the beginning of the first round-trip time of the congestion recovery phase, the number (dupwnd) of duplicate ACKs received at the sender side (i.e., the number of data packets in the inactive group) is initialized to zero. As duplicate ACKs arrive, the sender injects two new data packets for every three received duplicate ACKs. At the same time,
the state variable dupwnd counts the number of duplicate ACKs received. The end of the first round-trip time is indicated by the first arrival of non-duplicate ACKs (i.e., ACKs for higher sequence numbers, indicating that the retransmission was received). During the first round-trip time of the congestion recovery period, the active number actnum remains at zero. We call this period the damping phase. At the end of the first round-trip time of the congestion recovery period, the active number actnum assumes the role of sender flow control for the rest of the congestion recovery period. The variable actnum is initiallyset to dupwnd 2=3, which is the number of new data packets sent out during the first round-trip time of the congestion recovery period. In the second phase of the Dynamic Recovery algorithm, called the probe phase, the sender increases the value of actnum by one4 for every round-trip time, similar to the congestion avoidance algorithm. This process continues until the end of the congestion recovery phase, or until the detection of further packet losses. Since the TCP state variable snd.nxt is updated during each partial acknowledgement, any further packet losses during the congestion recovery phase can be detected by a partial acknowledgement that is beyond the snd.nxt value at the time the first packet loss was detected. If further packet losses occur, then we reset actnum to zero and recursively employ the Dynamic Recovery algorithm. In this case, the sender enters the damping subphase directly, without waiting for three further duplicate ACKs. After the sender recovers the most recently lost packet 5 , it exits the congestion recovery period and enters the congestion avoidance phase. At that time, the role of flow control is transferred back to the congestion window cwnd; the sender assigns the current value of actnum to cwnd, and sets actnum to zero again. From the above description, we can see that the first round-triptime of the congestion recovery phase (i.e., damping subphase) is important. It is during this period that the role of flow control at the sender side is transferred from the congestion window cwnd to the active number actnum. Note that the first lost packet is recovered in the damping subphase, and the remaining lost packets, if any, are recovered in the probe subphase (one per round trip time). Furthermore, it is during the probe subphase that the sender continues to probe the new equilibrium of the TCP connection. The sending TCP can distinguish between the two phases by testing if actnum is zero. 4 Note that the Dynamic Recovery algorithm obeys the rule of multiplicative decrease and linear increase for the number of new data packets transmitted in the damping and probe subphases, respectively. 5 This state is indicated by the arrival of a new ACK that is beyond the last updated snd.nxt (in the ns simulator, the corresponding state variable is recover ) at the time the last partial ACK arrived.
S1 8Mbps 0.1ms
R1
8Mbps 0.001ms
0.8Mbps 100ms
R2
K1
8Mbps 0.1ms
S2
Figure 7. Simulation topology used for Dynamic Recovery experiments.
4.4. Simulation setup We tested the Dynamic Recovery algorithm in the ns network simulator. Since New-Reno, SACK and FACK TCP are known to perform much better than Tahoe and Reno TCP in the presence of multiple packet losses, we focused on the performance comparison between Dynamic Recovery and New-Reno, SACK, and FACK TCP. To focus our analysis solely on the Dynamic Recovery algorithm, these experiments all use the conventional TCP Slow-Start algorithm, and not our modified Smooth-Start algorithm. The simulation topology for the Dynamic Recovery experiments is shown in Figure 7. There are two routers in this configuration. Each simulation for Dynamic Recovery has three TCP connections from S1 to K1. Only the first connection is shown in the graphs, since all connections experience similar TCP behaviour. The performance of congestion recovery was assessed by configuring the traffic flows in the simulator such that multiple packets were lost from a window of data during connection startup. Experiments were conducted with two, three, four, and six packet losses per window of data, similar to the experiments conducted in [4].
4.5. Simulation results The simulation results for the Dynamic Recovery algorithm are shown in Figure 8. These results are for a scenario with four lost packets from one window of data; the other scenarios produced qualitatively similar results. In Figure 8, the Dynamic Recovery algorithm provides the highest TCP throughput: 33% better than New-Reno, and 5-8% better than SACK and FACK TCP. The performance advantages of Dynamic Recovery are quite consistent across the two-drop, three-drop, four-drop, and six-drop scenarios, though the performance of FACK TCP and Dynamic Recovery are practically identical in the six-drop case. In any event, the Dynamic Recovery algorithm is quite robust to multiple packet losses from a window of data. It provides similar performance to SACK and FACK TCP, but with lower implementation complexity.
Table 1. State variables in the ns simulator. Name recover last recover maxseq seqno
Meaning of the State Variables the highest packet sent before receiving the latest dup ACKs. the highest packet sent when the first lost packet was detected. the highest sequence number sent so far. the sequence number indicated by the current received ACK.
New-Reno: Four_drops
SACK: Four_drops
packet
packet packets acks skip-1 drops
60.0000 55.0000
55.0000
50.0000
50.0000
45.0000
45.0000
40.0000
40.0000
35.0000
35.0000
30.0000
30.0000
25.0000
25.0000
20.0000
20.0000
15.0000
15.0000
10.0000
10.0000
5.0000
5.0000
0.0000
packets acks skip-1 drops
60.0000
0.0000 time 0.0000
1.0000
2.0000
3.0000
4.0000
5.0000
time
6.0000
0.0000
1.0000
2.0000
(a)
3.0000
4.0000
5.0000
6.0000
(b) FACK: Four_drops
Dynamic Recovery: Four_drops
packet
packet packets acks skip-1 drops
60.0000 55.0000
55.0000
50.0000
50.0000
45.0000
45.0000
40.0000
40.0000
35.0000
35.0000
30.0000
30.0000
25.0000
25.0000
20.0000
20.0000
15.0000
15.0000
10.0000
10.0000
5.0000
5.0000
0.0000
packets acks skip-1 drops
60.0000
0.0000 time 0.0000
1.0000
2.0000
3.0000
(c)
4.0000
5.0000
6.0000
time 0.0000
1.0000
2.0000
3.0000
4.0000
5.0000
6.0000
(d)
Figure 8. Simulation results for a scenario with four packet losses from one window of data: (a) New-Reno; (b) SACK; (c) FACK; (d) Dynamic Recovery.
5. Conclusions This paper proposes and evaluates two new mechanisms, Smooth-Start and Dynamic Recovery, to improve TCP congestion control in packet-switched networks. Both mechanisms are evaluated by simulation, and found to offer moderate to large performance advantages over existing TCP congestion control mechanisms, such as the Slow-Start and Fast Recovery mechanisms popularized in Tahoe, Reno, SACK, and FACK TCP. The Smooth-Start modification provides a more graceful approach to equilibrium state for a TCP connection, either initially, or following a retransmission timeout. With the combination of the Smooth-Start algorithm and the ssthresh estimator, the chance of experiencing multiple packet losses from a window of data is significantly decreased. By employing the Dynamic Recovery algorithm, TCP can recover from multiple packet losses from the same window of data, without any significant performance degradation. The key feature of the Dynamic Recovery algorithm is a variable-length recovery period, during which a sender recovers from packet losses, while also sending new packets to probe the new equilibrium of the TCP connection. In addition to the performance advantages offered by our scheme, there are implementation and interoperability advantages. In particular, the newly proposed scheme is much simpler than SACK TCP, and does not require selective acknowledgements or receiver modifications. All TCP modifications are at the sending side only. Furthermore, though not shown here, the new scheme interoperates reasonably well, in terms of fairness, with existing TCP implementations, making experimental introduction of the approach in the Internet a possibility.
Acknowledgements Financial support for this research was provided by TRLabs in Saskatoon and by the Natural Sciences and Engineering Research Council (NSERC) of Canada, through research grants OGP0121969 and CRD183839. The authors thank the anonymous MASCOTS’98 reviewers for their constructive comments on an earlier version of this paper.
References [1] J. Ahn, P. Danzig, Z. Liu, and L. Yan. Evaluation of TCP Vegas: Emulation and experiment. Proceedings of ACM SIGCOMM’95, pages 185–195, August 1995. [2] M. Arlitt and C. Williamson. Internet Web servers: Workload characterization and performance implications. IEEE/ACM Transactions on Networking, 5(5):631–645, October 1997.
[3] L. Brakmo, S. O’Malley, and L. Peterson. TCP Vegas: New technique for congestion detection and avoidance. Proceedings of ACM SIGCOMM’94, pages 24–35, August 1994. [4] K. Fall and S. Floyd. Simulation-based comparisons of Tahoe, Reno, and SACK TCP. ACM Computer Communication Review, 26(3):5–21, July 1996. [5] S. Floyd. Connections with multiple congested gateways in packet-switched networks, Part 1: One-way traffic. ACM Computer Communication Review, 21(5), October 1991. [6] S. Floyd. TCP and successive fast retransmits. ftp://ftp.ee.lbl.gov/papers/fastretrans.ps, February 1995. [7] S. Floyd and V. Jacobson. On traffic phase effects in packetswitched gateways. Internetworking: Research and Experience, 3(3):115–156, September 1992. [8] S. Floyd and V. Jacobson. Random Early Detection gateways for congestion avoidance. IEEE/ACM Transactions on Networking, 1(4):397–413, August 1993. [9] J. Hoe. Improving the start-up behavior of a congestion control scheme for TCP. Proceedings of ACM SIGCOMM’96, pages 270–280, August 1996. [10] V. Jacobson. Congestion avoidance and control. Proceedings of ACM SIGCOMM’88, pages 314–329, August 1988. [11] V. Jacobson. Berkeley TCP evolution from 4.3-Tahoe to 4.3Reno. Proceedings of the Eighteenth Internet Engineering Task Force, 1990. [12] V. Jacobson. Fast retransmit. Message to the end2end-ietf mailing list, April 1990. [13] M. Mathis and J. Mahdavi. Forward Acknowledgment (FACK): Refining TCP congestion control. Proceedings of ACM SIGCOMM’96, pages 281–291, August 1996. [14] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP selective acknowledgment option. Internet Draft, work in progress, May 1996. [15] M. Mathis, J. Semke, J. Mahdavi, and T. Ott. The macroscopic behavior of the TCP congestion avoidance algorithm. ACM Computer Communication Review, 27(3):67–82, July 1997. [16] S. McCanne and S. Floyd. ns-LBNL network simulator. http://www-nrg.ee.lbl.gov/ns/, 1996. [17] J. Mogul. Observing TCP dynamics in real networks. Proceedings of ACM SIGCOMM’92, pages 305–317, August 1992. [18] V. Paxson. End-to-end internet packet dynamics. Proceedings of ACM SIGCOMM’97, September 1997. [19] J. Postel. Transmission control protocol. Request for Comments 793, Network Information Center, September 1981. [20] W. Stevens. TCP/IP Illustrated, Volume 1. Addison-Wesley, New York, 1994. [21] Z. Wang and J. Crowcroft. A new congestion control scheme: Slow-start and search (Tri-S). ACM Computer Communication Review, 21(1):32–43, January 1991. [22] L. Zhang. Observations on the dynamics of a congestion control algorithm: The effects of two way traffic. Proceedings of ACM SIGCOMM’91, pages 133–148, September 1991.
