Results 1 - 10
of
102
Modeling TCP Throughput: A Simple Model and its Empirical Validation
, 1998
"... In this paper we develop a simple analytic characterization of the steady state throughput, as a function of loss rate and round trip time for a bulk transfer TCP flow, i.e., a flow with an unlimited amount of data to send. Unlike the models in [6, 7, 10], our model captures not only the behavior of ..."
Abstract
-
Cited by 988 (35 self)
- Add to MetaCart
In this paper we develop a simple analytic characterization of the steady state throughput, as a function of loss rate and round trip time for a bulk transfer TCP flow, i.e., a flow with an unlimited amount of data to send. Unlike the models in [6, 7, 10], our model captures not only the behavior of TCP’s fast retransmit mechanism (which is also considered in [6, 7, 10]) but also the effect of TCP’s timeout mechanism on throughput. Our measurements suggest that this latter behavior is important from a modeling perspective, as almost all of our TCP traces contained more timeout events than fast retransmit events. Our measurements demonstrate that our model is able to more accurately predict TCP throughput and is accurate over a wider range of loss rates. This material is based upon work supported by the National Science Foundation under grants NCR-95-08274, NCR-95-23807 and CDA-95-02639. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.
A Proposal to add Explicit Congestion Notification (ECN) to IP
, 1999
"... This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. TCP is currently the dominant transport protocol used in the Internet. We begin by describing TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue manage ..."
Abstract
-
Cited by 368 (23 self)
- Add to MetaCart
This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. TCP is currently the dominant transport protocol used in the Internet. We begin by describing TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers could instead set a Congestion Experienced (CE) bit in the packet header of packets from ECN-capable transport protocols. We describe when the CE bit would be set in the routers, and describe what modifications would be needed to TCP to make it ECN-capable. Modifications to other transport protocols (e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process. 1. C...
Dynamics of Random Early Detection
, 1997
"... In this paper we evaluate the effectiveness of Random Early Detection (RED) over traffic types categorized as nonadaptive, fragile and robust, according to their responses to congestion. We point out that RED allows unfair bandwidth sharing when a mixture of the three traffic types shares a link. Th ..."
Abstract
-
Cited by 368 (1 self)
- Add to MetaCart
In this paper we evaluate the effectiveness of Random Early Detection (RED) over traffic types categorized as nonadaptive, fragile and robust, according to their responses to congestion. We point out that RED allows unfair bandwidth sharing when a mixture of the three traffic types shares a link. This unfairness is caused by the fact that at any given time RED imposes the same loss rate on all flows, regardless of their bandwidths. We propose Flow Random Early Drop (FRED), a modified version of RED. FRED uses per-active-flow accounting to impose on each flow a loss rate that depends on the flow's buffer use. We show that FRED provides better protection than RED for adaptive (fragile and robust) flows. In addition, FRED is able to isolate non-adaptive greedy traffic more effectively. Finally, we present a "two-packet-buffer" gateway mechanism to support a large number of flows without incurring additional queueing delays inside the network. These improvements are demonstrated by simulation of TCP and UDP traffic. FRED
The performance of TCP/IP for networks with high bandwidth-delay products and random loss
, 1997
"... This paper examines the performance of TCP/IP, the Internet data transport protocol, over Wide Area Networks (WANs) in which data traffic could coexist with real-time traffic such as voice and video. Specifically, we attempt to develop a basic understanding, using analysis and simulation, of the pro ..."
Abstract
-
Cited by 359 (6 self)
- Add to MetaCart
This paper examines the performance of TCP/IP, the Internet data transport protocol, over Wide Area Networks (WANs) in which data traffic could coexist with real-time traffic such as voice and video. Specifically, we attempt to develop a basic understanding, using analysis and simulation, of the properties of TCP/IP in a regime where (1) the bandwidth-delay product of the network is high compared to the buffering in the network, and (2) there may be transient congestion due to fluctuations in real-time traffic, modeled here as producing random losses among the packets of the TCP connection of interest. The following key results are obtained. First, random loss leads to significant throughput deterioration when the product of the loss probability and the square of the bandwidth-delay product is larger than one. Unless network resources are specifically reserved for data traffic, data traffic will inevitably incur random losses due to transient fluctuations in higher priority real-time traffic when the network is highly utilized. Second, for multiple connections sharing a bottleneck link, TCP is grossly unfair towards connections with higher round-trip delays. This means that a simple First In First Out (FIFO) queueing discipline might not suffice for data traffic in WANs. Finally, we observe that, while the recent Reno version of TCP produces less bursty traffic than the original Tahoe version, it is less robust than the latter when successive losses are closely spaced. We conclude by indicating modifications that may be required both at the transport and network layers to provide good end-to-end performance over high-speed WANs.
Modeling TCP Reno Performance: A Simple Model and Its Empirical Validation
- IEEE/ACM Transactions on Networking
, 2000
"... Abstract—The steady-state performance of a bulk transfer TCP flow (i.e., a flow with a large amount of data to send, such as FTP transfers) may be characterized by the send rate, which is the amount of data sent by the sender in unit time. In this paper we develop a simple analytic characterization ..."
Abstract
-
Cited by 243 (4 self)
- Add to MetaCart
Abstract—The steady-state performance of a bulk transfer TCP flow (i.e., a flow with a large amount of data to send, such as FTP transfers) may be characterized by the send rate, which is the amount of data sent by the sender in unit time. In this paper we develop a simple analytic characterization of the steady-state send rate as a function of loss rate and round trip time (RTT) for a bulk transfer TCP flow. Unlike the models in [7]–[9], and [12], our model captures not only the behavior of the fast retransmit mechanism but also the effect of the time-out mechanism. Our measurements suggest that this latter behavior is important from a modeling perspective, as almost all of our TCP traces contained more time-out events than fast retransmit events. Our measurements demonstrate that our model is able to more accurately predict TCP send rate and is accurate over a wider range of loss rates. We also present a simple extension of our model to compute the throughput of a bulk transfer TCP flow, which is defined as the amount of data received by the receiver in unit time. Index Terms—Empirical validation, modeling, retransmission timeouts, TCP.
Improving the Start-up Behavior of a Congestion Control Scheme for TCP
, 1996
"... Based on experiments conducted in a network simulator and over real networks, this paper proposes changes to the congestion control scheme in current TCP implementations to improve its behavior during the start-up period of a TCP connection. The scheme, which includes Slow-start, Fast Retransmit, a ..."
Abstract
-
Cited by 217 (0 self)
- Add to MetaCart
Based on experiments conducted in a network simulator and over real networks, this paper proposes changes to the congestion control scheme in current TCP implementations to improve its behavior during the start-up period of a TCP connection. The scheme, which includes Slow-start, Fast Retransmit, and Fast Recovery algorithms, uses acknowledgments from a receiver to dynamically calculate reasonable operating values for a sender's TCP parameters governing when and how much a sender can pump into the network. During the startup period, because a TCP sender starts with default parameters, it often ends up sending too many packets and too fast, leading to multiple losses of packets from the same window. This paper shows that recovery from losses during this start-up period is often unnecessarily time-consuming. In particular, using the current Fast Retransmit algorithm, when multiple packets in the same window are lost, only one of the packet losses may be recovered by each Fast Retransmi...
The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions
- ACM Computer Communication Review
, 2000
"... We propose an enhancement to TCP’s error recovery scheme, which we call the Eifel algorithm. It eliminates the retransmission ambiguity, thereby solving the problems caused by spurious timeouts and spurious fast retransmits. It can be incrementally deployed as it is backwards compatible and does not ..."
Abstract
-
Cited by 143 (6 self)
- Add to MetaCart
We propose an enhancement to TCP’s error recovery scheme, which we call the Eifel algorithm. It eliminates the retransmission ambiguity, thereby solving the problems caused by spurious timeouts and spurious fast retransmits. It can be incrementally deployed as it is backwards compatible and does not change TCP’s congestion control semantics. In environments where spurious retransmissions occur frequently, the algorithm can improve the end-to-end throughput by several tens of percent. An exact quantification is, however, highly dependent on the path characteristics over time. The Eifel algorithm finally makes TCP truly wireless-capable without the need for proxies between the end points. Another key novelty is that the Eifel algorithm provides for the implementation of a more optimistic retransmission timer because it reduces the penalty of a spurious timeout to a single (in the common case) spurious retransmission. 1.
The Addition of Explicit Congestion Notification (ECN) to IP
, 2001
"... This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. Table of Contents 1. ..."
Abstract
-
Cited by 129 (7 self)
- Add to MetaCart
This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. Table of Contents 1.
A Self-Configuring RED Gateway
, 1999
"... The congestion control mechanisms used in TCP have been the focus of numerous studies and have undergone a number of enhancements. However, even with these enhancements, TCP connections still experience alarmingly high loss rates, especially during times of congestion. The IETF has addressed this pr ..."
Abstract
-
Cited by 127 (10 self)
- Add to MetaCart
The congestion control mechanisms used in TCP have been the focus of numerous studies and have undergone a number of enhancements. However, even with these enhancements, TCP connections still experience alarmingly high loss rates, especially during times of congestion. The IETF has addressed this problem by advocating the deployment of active queue management mechanisms, such as RED, in the network. While RED can potentially improve packet loss rates, we show that its effectiveness is highly dependent upon its operating parameters. In fact, in cases where these parameters do not match the requirements of the network load, the performance of the RED gateway can approach that of a traditional drop-tail gateway. To alleviate this problem, we propose and experiment with a self-configuring active queue management mechanism which can significantly reduce loss rates across congested links. When used in the network, this mechanism can effectively reduce packet loss while maintaining high link utilizations under the most difficult scenarios. Keywords: Congestion control, Internet, TCP, RED, queue management 1
Understanding the Performance of TCP Pacing
, 2000
"... Many researchers have observed that TCP's congestion control mechanisms can lead to bursty traffic flows on modern high-speed networks, with a negative impact on overall network efficiency. A proposed solution to this problem is to evenly space, or "pace", data sent into the network over an entire ..."
Abstract
-
Cited by 101 (3 self)
- Add to MetaCart
Many researchers have observed that TCP's congestion control mechanisms can lead to bursty traffic flows on modern high-speed networks, with a negative impact on overall network efficiency. A proposed solution to this problem is to evenly space, or "pace", data sent into the network over an entire round-trip time, so that data is not sent in a burst. In this paper, we quantitatively evaluate this approach. We show that pacing offers better fairness, throughput, and lower drop rates in some situations. However, contrary to our initial intuition, pacing often has significantly worse throughput than regular TCP because it is susceptible to synchronized losses. We propose and evaluate approaches for eliminating this effect.

