Bandwidth feedback control of TCP and real time sources in the Internet

Bandwidth feedback control of TCP and real time sources in the Internet Mario Gerla1 , Wenjie Weng2 , Renato Lo Cigno3 1

Computer Science Department, UCLA, California, USA 2 Motorola, Inc., San Diego, California, USA 3 Dipartimento di Elettronica, Politecnico di Torino, Italy

Abstract— This paper proposes a feedback-based algorithm for congestion control and bandwidth allocation in the presence of either TCP traffic or both TCP and real-time traffic. In this proposal, the network layer conveys bandwidth and propagation delay measurements to data sources, for instance using IPv6 optional fields. TCP sources use this bandwidthdelay product to control their congestion window, while video sources use the available bandwidth feedback to adjust their data sending rate. The experiments show that with this approach, the network achieves stable equilibrium, and users, either transmitting TCP traffic or real-time traffic, can share network resources fairly. Furthermore, since TCP sources learn about the available bandwidth independent of packet loss, there is no need to reduce the congestion window following a packet loss. This provides a way to improve TCP performance in wireless networks where it is difficult to distinguish between congestion loss and radio channel interference loss.

among competing flows; to maintain high utilization of the bottleneck link; and to prevent performance degradation due to the presence of wireless links. The last requirement is becoming increasingly important as mobile, wireless access to the Internet (via cellular or satellite links) is growing at a phenomenal rate. We shall focus on best-effort traffic control. For real-time traffic, we consider rate adaptive video sources using CBR transport. In the following sections, we shall review theoretical background of the feedback-based algorithm followed by the implementation in the network and transport layers and the simulation experiments. II. BACKGROUND

I. I NTRODUCTION The boom of the Internet is stressing the entire IP protocol implementation, as users grow in number, along with the demand for enhanced service and performance. Currently, the majority of data services in the Internet are based on TCP (Transport Control Protocol) with application ranging from bulk data transmission (like FTP file transfers), to interactive, delay sensitive services (like Telnet remote terminal), and web browsing. TCP provides a connection oriented, reliable communication channel to upper layers. It also provides the functions of receiver flow control and network congestion control. There is growing demand for transporting compressed video traffic over the Internet. Some of these applications are delay sensitive and require guaranteed quality of service (QoS). Depending on the desired quality and potential cost to the user, many of these applications can tolerate some variability in the perceived quality of the video. These include video teleconferencing, interactive training, low-cost news distribution, and possibly even entertainment video. It is known that compressed video is inherently bursty with rate fluctuations over multiple time scales. To better manage network resources and congestion control and to make admission control simple, some researchers suggested the use of Constant Bit Rate (CBR) transport for video streams by employing a local buffer for smoothing and by adjusting the video encoding parameters [1]. It has also been proposed to adapt sending rate of real-time streams either based on the feedback of packet loss from end receivers [2] or through frequent negotiation for bandwidth between the source and the network [3]. These proposals assume that the compressed video sources are rate adaptive, in that it is possible to adjust the source rate dynamically by modifying the video encoding parameters so as to be responsive to the network conditions. This paper presents a bandwidth feedback algorithm for congestion control and fair bandwidth allocation. The main goals are: to provide a unified congestion control scheme suitable for a mix of TCP and real-time traffic; to divide bandwidth fairly This work was supported by NASA contract NAG2-1249, by NSF contract 8NI9805436, and by the Italian Ministry of University and Scientific Research through the MQOS contract.

OF THE FEEDBACK- BASED ALGORITHM

The feedback-based algorithm is originated from the study of a fluid dynamic model. Suppose at time t, a source, S , transmits fluid at a rate of rs (t) through a pipe to a downstream destination, D, which consumes it at a rate of rd (t). Here, rs (t) and rd (t) are time dependent variables. There is a container at D which holds the arriving fluid not being consumed immediately. Let ra (t) be the arriving rate at D, then ra (t) = rs (t Æt) where Æt is the time delay from the source to the destination. If Rd is the upper bound of rd (t), the destination consumes the fluid at rate Rd when ra (t)  Rd or when the container is not empty. When ra (t) < Rd and the container is empty, rd (t) = ra (t). To avoid overflowing the container, its capacity C must be greater than q (t) where

q(t) =

Z

0

t

[rs (

Æt) rd ( )℄ d:

(1)

This equation suggests that with the maximum consuming rate Rd fixed, we need to control rs (t) such that q (t) is smaller than C to prevent overflow. Mathematically, rs (t) can be solved by Laplace transform for the continuous fluid model, and its solution depends on q (t). This indicates that in order to control the source sending rate, the source must have information about the container’s occupancy at the destination. A recent work [4] applied the fluid model to a discrete system, i.e., TCP data traffic in the Internet, and found an analytical solution to (1). It then suggests that with the explicit feedback of available buffer space at routers, a TCP source can control its window size such that there is no packet loss due to congestion. However, the fairness problem has to be solved by perflow queuing with round-robin scheduling. Following upon that work, a Generalized Window Advertising (GWA) scheme for TCP congestion control is proposed [5]. The basic idea of GWA is depicted in a schematic diagram shown in Fig. 1. At source S, each data packet is tagged (with IPv6 header, say) with an available buffer space Bn initialized to a maximum value, Bmax . Router R1 updates Bn in the packet only if its available buffer space Bav is smaller than Bn . Router R2 updates Bn the same way as router R1. When the packet arrives at the destination D, the receiver compares its available buffer space Br with Bn and puts the minimum of the two into the receiver’s advertized

B n = Bmax

information flow control flow B n = min (Bn, Bav)

Wt = min (Wc ,Wa ) - W u

Wa = min (B r , Bn) R1

S

R2

D

Fig. 1. A schematic diagram for a TCP congestion control utilizing network feedback.

window Wa in TCP header. Upon receiving the ACK packet, the source uses the receiver’s advertized window to control its congestion window, as it does in current TCP implementations. In the GWA TCP scheme, the receiver’s advertized window is “generalized” to convey both receiver’s available buffer space and network available buffer, i.e., congestion status. As a result, it decouples the error recovery capability of TCP from its congestion control capability because packet loss is no longer treated as an indication of congestion. As shown in [5], GWA TCP has stable performance in congestion control, can achieve fair allocation of bandwidth and high utilization of network resource, and is friendly to existing TCPs. However, this performance improvement does not come for free. First, in order to achieve fair allocation of network resources, network routers must employ an expensive per-flow queuing which is undesirable and especially not practical in high speed networks with thousands of connections. Second, in high speed network with long propagation delay, IP routers must have huge buffer sizes (of at least round-trip delay-bandwidth product for GWA TCP) to achieve high utilization of bandwidth. To overcome these implementation difficulties and at the same time achieve good performance similar to the GWA scheme, this paper proposes a feedback-based algorithm in which network layer provides explicit information not of buffers, but of available bandwidth and propagation delay. The end hosts use this information to adjust their congestion window and sending rate. We provide estimated available bandwidth for the best-effort traffic so that other types of data traffic can coexist with minimal interference. In the next section, we discuss the feedback-based algorithm for TCP and real-time applications. III. T HE

FEEDBACK - BASED APPROACH

A. Functions in IP routers In the feedback-based approach, an IP router is assumed to know the propagation delay for each outgoing link connected to it and is able to compute the bandwidth Bi available for each flow. One way of estimating link delay is by sending data between two adjacent nodes (“pinging”) during light load. The bandwidth of an outgoing link can be estimated by directly measuring the throughput of the link during a busy period, when queue is not empty. Then, the round-trip propagation delay Rt is obtained by summing all the link delays in both forward and backward paths. The available bandwidth for a flow, Ba , is the minimum of the available bandwidths (Bi for i = 1; 2; :::; m, assume m links along the path) offered by the links in the forward path. The ith IP router computes the available bandwidth for an outgoing link Bi (t) as follows

Bi (t) = B=n^(t);

(2)

^ is the where B is the total bandwidth of the outgoing link and n number of active flows. By using IPv6 with a round-trip propagation delay (RTPD) field and an available bandwidth (ABW)

field in IPv6’s extended header, Rt and Ba can be obtained from the network layer and conveyed to the end users. Estimating the number of active flows is a challenge since various types of data traffic may be present in the network, such as small, short-lived and large, long-lived connections. Some longlived connections are greedy for bandwidth and others may need less bandwidth than their fair share. With these considerations, we compute the number of active flows based on the exponential averaging filter,

n^(t) = n^ (t  ) + (1 )n(t); where  is a tuning parameter in the range [0,1] and computed by

n(t) = m(t) +

X p t =p t :

(3)

n(t)

is

I

i(

) ( )

(4)

i=1

Here, p(t) is the total bytes transmitted during time interval ( t  , t) divided by the total number (i.e., m + I ) of flows observed during the same interval; m and I are the number of flows with at least p and smaller than p bytes transmitted by the router, respectively. Here, is a predefined parameter and is set to 0.8 in our simulation. pi (t) is the number of bytes transmitted by ^ (0) is set the router for the ith flow during (t  , t). Initially, n to 1. We should note that the main point of our proposal is the overall architecture. While the detailed design presented here serves adequately as a proof of our scheme, it represents only a prototype and will continue to evolve. With this prototype of IP routers, we implemented a Bandwidth Aware TCP (BATCP) and an Adaptive CBR (ACBR) which utilize the feedback from the network to control their sending rates. In this feedbackbased approach, we assume that all packets of a connection follow the same forward and backward paths, as is the case in typical internet conditions. The following two subsections present BA-TCP and ACBR implementation. B. Implementation of BA-TCP In BA-TCP, the connection setup packets (SYN) with RTPD field in IPv6 are used for obtaining a connection’s round-trip propagation delay. The data packets with ABW field in IPv6 are used for obtaining available bandwidth of the forward path of the connection. Both the round-trip propagation delay and the available bandwidth are conveyed to the TCP receiver. As a consequence, the modification to the TCP receiver is (i) add a state variable for storing the round-trip propagation delay Rt upon receiving it from the connection setup packets (SYN); (ii) after receiving a data packet with available bandwidth notification, the receiver computes Ba Rt and puts the minimum between Ba Rt and the initial rwndin in the receiver’s advertized window field rwndout in the ACK packet. Namely, rwndout = min (Ba Rt , rwndin ). With this modification, the advertized window field in ACK packets is “generalized” to combine both flow control and congestion control. The TCP transmitter reacts to the receiver’s advertized window the same way as in conventional TCP. In the absence of receiver buffer constraints (declared in rwndin ), the window Ba Rt guarantees that the “pipe is kept full”, which is the optimal operating condition for a sliding window protocol [6]. Moreover each flow gets equal share of bandwidth. BA-TCP maintains slow start mechanism at initial transmission and enters congestion avoidance phase when the congestion window exceeds the slow start threshold. When packet loss

The main objectives of the ACBR scheme are to provide best effort for the real time, adjustable traffic without dropping too many data packets upon congestion and at the same time to reduce the interference between real time and TCP traffic. ACBR hosts use network feedback to control the data sending rate. In the proposed ACBR scheme, each data packet is tagged with an available bandwidth field in the IPv6 extended header. The network feedback of the available bandwidth is delivered to the ACBR receiver, which stores the value in a state variable Br . The receiver periodically sends an acknowledgment (ACK) packet containing the available bandwidth to the source. Upon receiving the ACK packet, the source updates its sending rate to the available bandwidth. IV. S IMULATION

EXPERIMENTS

We implemented the feedback-based algorithm in ns-2 [8]. We introduce RTPD and ABW fields in IPv6 header and add functions in IP routers to update these fields if needed. The drop-tail queuing discipline with first-come first-served scheduling (no per flow queuing) is used at routers. In ACBR implementation, an ACBR source sends data packets with sequence number for the purpose of helping data receiver to detect packet loss. The ACBR receiver periodically sends an ACK packet with available bandwidth as described in previous section. BA-TCP is implemented by superimposing BA features on top of Reno TCP, which implements the most commonly used congestion control mechanisms, such as Slow-Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery algorithms ([9], [10]). The following three subsections present the performance of the feedback-based algorithm obtained from our simulation experiments. For comparison, the simulation results obtained by Reno TCP combined with Random Early Detection (RED) [11] router are also presented. For RED routers, the minimum and maximum thresholds of the average queue length is set to 1/12 and 3/12 of the buffer size. In our simulations, TCP clock granularity is set to 0.1 seconds and the TCP receiver’s window size is 512 Kbytes. All simulations are run for 100 seconds. A. TCP traffic in a wired network We investigate the performance of the proposed scheme in a simple wired network (see Fig. 2), where source node Si sends data to destination node Di (for i=1, 2, ..., N) through routers G1 and G2. The propagation delay between G1 and G2 is 30 ms and is 5 ms for all the other links. The bandwidth of a link is B and is assumed to be the same for all the links.

B

B

S2

D1

D2

5 ms

G1

Si

B

5 ms

G2

30 ms

Di

DN

SN

Fig. 2. A simulation topology. (a)

BA-TCP

(b)

sequence number (Kbytes)

C. Implementation of Adaptive CBR

S1

sequence number (Kbytes)

is indicated by reception of three duplicate ACKs, the source does not reduce the congestion window after the fast retransmit. More specifically, BA-TCP implements the conventional fast retransmit and fast recovery except that it does not reduce its window size and slow start threshold after fast retransmit. Thus, the main difference is the disabling of the slow start mechanism. Like current TCPs, timeout of a retransmission timer invokes retransmission of one data packet. To maintain backward compatibility, we suggest to implement BA-TCP by superimposing BA features on top of a current TCP and use one of the reserved bits in TCP header for a pair of sender and receiver to exchange information of whether the other end is BA capable (i.e., have BA features implemented) during connection setup. See [7] for more discussions of BATCP implementation.

800 600 400 200 0

0

1 2 3 4 send time (seconds)

5

Reno-TCP

800 600 400 200 0

0

1 2 3 4 send time (seconds)

5

Fig. 3. The sequence number sent by ten sources in a simulation scenario shown in Fig. 2 with N=10 and B=10Mbps when (a) BA-TCP or (b) Reno TCP is used.

We first consider a case with 10 connections (i.e., N=10 in Fig. 2). Each source node has an FTP source with infinite backlog. The size of the TCP segments is 1 Kbyte. The start times for the sources are randomly and uniformly distributed over the first 3 seconds of the simulation. The bandwidth of all links is 10 Mbps. The buffer size at routers is set to 100 Kbytes, which is the (round-trip propagation delay bandwidth) product. Fig. 3(a) shows the sequence numbers sent by the ten BATCP sources during the first 5 seconds of the simulation. The steady increase of the sequence number for each flow indicates stable congestion control and a smooth transition when new connections become active. After 3 seconds of simulation, all sources have throughput close to 1 Mbps, which is a connection fair share of the bandwidth at the bottleneck link. Simulations with B=100 Mbps for all the links produce similar results to Fig. 3(a), except that sequence number increases much faster. As a comparison, we run simulation with the same topology and parameters except that Reno TCP and RED routers were used. As can be seen in Fig. 3(b), the sequence number fluctuates with time. The unfair share of the bandwidth is clearly seen here since during any time interval, the sequence number increase of some sources is faster than that of the others. When all the links have bandwidth of 100 Mbps, the roundtrip propagation delay-bandwidth product is 1 Mbyte. We examined BA-TCP performance in the cases when routers’ buffer size is below this value. Fig. 4 shows the throughput for all the connections when BA-TCP and Reno TCP are used. Flow ID i in the figure represents the connection i from source Si to destination Di. When the buffer size is set to 128 [Fig. 4(a)] and 256 Kbyte [Fig. 4(b)], the throughput of the BA-TCP sources is around 10 Mbps. There are few BA-TCP sources whose throughput is slightly smaller than 10 Mbps. This is because when the routers’ buffer size is too small, the bursty nature of the TCP sources can lead to packet loss. When BA-TCP is implemented on top of Reno TCP, only one data packet can be recovered for each RTT. However, when the buffer size is 384

60

0

200 400 Buffer size (KB)

600

BA-TCP

Throughput (Mbps)

Fig. 6. The throughput obtained by BA-TCP sources in a simulation scenario shown in Fig. 2 with N=10 and B=100 Mbps.

Reno TCP

0.02 0.01 0 0

0 1 2 3 4 5 6 7 8 9 Flow ID

200 400 Buffer size (KB)

600

Fig. 5. The corresponding total throughput (in Mbps) and dropping rates of the simulation shown in Fig. 4.

and 512 Kbyte, all 10 BA-TCP sources obtained throughput of about 10 Mbps [Figs. 4(c) and (d)]. All in all, BA-TCP basically achieves fair share of bandwidth without per-flow queuing and with much smaller buffer size at routers as compared with 1 Mbyte. When Reno TCP combined with RED routers is used, there is unfair allocation of bandwidth among the competing flows although all the connections have the same propagation delay (open circles in Fig. 4). We notice that when simulations are run long enough, Reno TCP with RED routers can achieve fair share of the bandwidth. Fig. 5 shows the total throughput and dropping ratio for the simulations shown in Fig. 4. When BA-TCP is used, the total throughput is very close to the bandwidth offered by the bottleneck link (i.e., 100 Mbps). We observed some packet loss during the initial transient time. At steady state, no packet loss is observed in these simulations. When Reno TCP is used, the total throughput achieved by the ten sources increases with the buffer size and is around 80 Mbps. The packet dropping ratio increases with the decrease of buffer size as show in Fig. 5(b). We further investigate BA-TCP performance in a case that source 0 generates data at a rate of 2 or 4 Mbps and the rest nine sources have infinite backlogged data to send. Our simulation results show that flow 0 gets throughput of 2 Mbps [Fig.6(a)] and 4 Mbps [Fig.6(b)] as it needs and the rest share the remaining 98 and 96 Mbps equally. Again, the total throughput for both cases is about 100 Mbps. B. Mixed TCP and real time traffic This subsection tests the performance of our feedback-based algorithm by introducing TCP and real-time traffic in the network. The simulation topology is similar to Fig. 2 except that now each host consists of one BA-TCP and one ACBR sources. All BA-TCP sources are “FTP” sessions with an infinite backlogged data to send. All ACBR sources are assumed to have a very high top data rate such that they will always use the maximum allowed rate. That is, the source keeps adjusting its sending rate to the available bandwidth advertized by the network. Fig. 7(a) shows the simulation results for total of 20 connections, in which 10 of them are BA-TCP connections and the other 10 are ACBR connections. The symbols cross and open circle represent the maximum and minimum throughput obtained by the BA-TCP sources, respectively, and the symbols plus and open box represent the maximum and minimum throughput obtained by the ACBR sources, respectively. The simulations are

6

(a) 20 flows

5 4

60

0 200 400 600 Buffer size (Kbyte) (b) 20 flows

50 40 30

0 200 400 600 Buffer size (Kbyte)

In top figures: In bottom figures:

3

(c) 40 flows

2 1

60

0 200 400 600 Buffer size (Kbyte) (d) 40 flows

50 40 30

0 200 400 600 Buffer size (Kbyte)

Max TCP throughput Max ACBR throughput Total TCP throughput

Throughput (Mbps)

80

(b)

0.03

0 1 2 3 4 5 6 7 8 9 Flow ID

(b) 12 10 8 6 4 2 0

Throughput (Mbps)

Reno TCP

(a)

Throughput (Mbps)

BA-TCP

12 10 8 6 4 2 0

Throughput (Mbps)

Total throughput

(a)

Dropping ratio (%)

Fig. 4. The sources’ throughput obtained by BA-TCP (crosses) and Reno TCP (open circles) in a simulation scenario shown in Fig. 2 with N=10 and B=100 Mbps. bs on the top of each figure represents buffer size.

100

Throughput (Mbps)

0 2 4 6 8 Flow ID

Throughput (Mbps)

0 2 4 6 8 Flow ID

(d) bs=512 KB 10 9 8 7 6

Throughput (Mbps)

0 2 4 6 8 Flow ID

(c) bs=384 KB 10 9 8 7 6

Throughput (Mbps)

(b) bs=256 KB 10 9 8 7 6

Throughput (Mbps)

0 2 4 6 8 Flow ID

Throughput (Mbps)

Throughput (Mbps)

(a) bs=128 KB 10 9 8 7 6

3

(e) 80 flows

2 1

60

0 200 400 600 Buffer size (Kbyte) (f) 80 flows

50 40 30

0 200 400 600 Buffer size (Kbyte)

Min TCP throughput Min ACBR throughput Total ACBR throughput

Fig. 7. The throughput for various number of flows.

done with buffer size of 128, 256, 384, or 512 Kbyte at routers. For all cases, the maximum and minimum throughputs of the ACBR connections are very close and are slightly larger than the maximum throughput obtained by BA-TCP sources. The total throughput obtained by the 10 ACBR sources is slightly larger than that by the 10 BA-TCP sources [Fig. 7(b)]. We did simulations for various total number of flows as shown in Figs. 7(c)-(f). All these results suggest that with the feedback-based algorithm, BA-TCP and ACBR sources can transmit data packets such that its throughput is close to its fair share of the bandwidth at the bottleneck link. To investigate the potential interference between a bunch of short-lived connections randomly distributed in time and longlived connections, we test a case with 1040 connections going through a bottleneck link (i.e., N=1040 in Fig. 2). Among the 1040 connections, there are 20 ACBR connections and 20 BA-TCP connections with infinite data to send. These connections can adapt to the network congested state. The start time of the 40 connections are uniformly and randomly distributed within the first 3 seconds of the simulation. The remaining 1000 connections are short-lived and use BA-TCP to send data. The file sizes sent by these connections are randomly chosen from 5 to 15 Kbytes. The initial transmission time of the 1000 connections are uniformly and randomly distributed over the 100-second simulation time. Our simulation results show that the throughput of the FTP and ACBR sources is around 2.5 Mbps [Fig. 8(a)]. The slightly larger throughput obtained by the ACBR sources reflects a slight underestimate of the number of active flows due to the randomly distributed short-lived connections. Since the ACBR sources get more bandwidth than their fair share, the throughput obtained by the FTP sources decreases. However, the slight underestimate of the active flows has no significant effect on the bandwidth allocation when all the long-lived connections are of the FTP type [Fig. 8(b)].

(a)

FTP flows

ACBR flows

2 1

0

5

10 15 20 25 30 35 40 Flow ID

Throughput (Mbps)

Throughput (Mbps)

3

3

(b)

FTP flows

2 1

0

5

10 15 20 25 30 35 40 Flow ID

Fig. 8. The throughput for (a) 20 FTP flows and 20 ACBR flows, and (b) 40 FTP flows in a simulation scenario shown in Fig. 2 with N=1040 and B=100 Mbps.

S

10 Mbit/s 40 ms

2 Mbit/s

BS

D 0.01 ms

Fig. 9. A simple wireless topology.

C. BA-TCP performance in a wireless network The TCP congestion control mechanism in standard implementations is based on a wired network model with very reliable nodes and links. Packet loss is mostly caused by buffer overflow and is thus taken as indication of congestion. With the presence of wireless (e.g., cellular and satellite) networks, conventional TCP experiences substantial performance degradation ([12], [13], [14]) due to its inability of discriminating between packet losses driven by network congestion and those caused by link errors or environment conditions. In BA-TCP, the source is aware of the available bandwidth through the feedback from network layer. This decouples the error recovery capability of TCP from its congestion control capability. Here, we test the performance of BA-TCP in a simple wireless network shown in Fig. 9, in which a source S sends data through a wired link to a base station BS, which in turn forwards it to a mobile host D. We introduce random errors in the wireless link for both forward and backward paths. The packet loss rate due to link error is one percent, representing a bit error rat e of 1.25*10 6. Our simulation experiment shows that when the router’s buffer size is 32, 64, or 128 Kbytes, the throughput of the BATCP source is about 1.98, 1.93, and 1.98 Mbps, respectively, which are close to the bandwidth provided by the wireless link (i.e., 2 Mbps). Because the BA-TCP source is aware of the available bandwidth, packet loss due to link error does not lead to congestion window shrink. When Reno TCP is used, the data throughput is 0.96, 0.98, and 0.98 Mbps when the buffer size is 32, 64, and 128 Kbytes, respectively. Therefore, its throughput is much smaller than the throughput achieved by BA-TCP source. The different buffer sizes used here do not have significant effect on Reno TCP’s performance, probably due to that packet loss caused by link error brings the average queue length below the minimum threshold during most of the time in the simulation. V. C ONCLUSIONS The study of fluid dynamic model and its application in TCP data traffic suggest that in order to provide smooth congestion control, network must provide explicit information of network resources to end users. Based on the theoretical framework, we propose a feedback-based algorithm using IPv6’s extended headers to convey to the end user the available bandwidth and propagation delay for controlling congestion window or sending rate. With the feedback-based approach, we are able to provide a uniform congestion control scheme when both TCP and real-

time traffics are present in the network. We implemented the feedback-based algorithm in TCP (called BA-TCP) and in CBR (called ACBR) in ns-2 . For backward compatibility, both BA-TCP and ACBR are implemented by superimposing the feedback features on top of a current TCP and CBR, respectively. BA-TCP and ACBR are in an effort to maintain end-to-end semantics of transport protocols. Our simulation results show that the feedback-based approach ensures stable behavior in congestion control and achieves high utilization of the bottleneck link. It can allocate bandwidth fairly among competing flows with the presence of BA-TCP and ACBR data traffic and the randomly distributed short flows. Furthermore, since the feedback-based algorithm provides end users with explicit congestion control scheme based on network feedback, it decouples the error recovery capability of TCP from its congestion control capability. This feature is important for BA-TCP application in the wireless networks. Our experiment shows that in a WAN environment, BA-TCP improves the current TCP performance by double the throughput. ACKNOWLEDGMENTS This work was done while Wenjie Weng was doing her postdoctoral research at the Computer Science Department of the University of California, Los Angeles. We wish to thank Medy Sanadidi, Saverio Mascolo, and the anonymous reviewers for their comments and suggestions. R EFERENCES [1] M. Grossglauser, S. Keshav, D. Tse, “RCBR: A simple and efficient service for multiple time-scale traffic”, Proceedings of the ACM SIGCOMM’95 Conference, Sept. 1995. [2] R. Rejaie, M. Handley, D. Estrin, “RAP: An end-to-end rate-based congestion control mechanism for realtime streams in the Internet”, Proceedings of IEEE Infocom’99, March 1999. [3] T. V. Lakshman, P. P. Mishra, K. K. Ramakrishnan, “Transporting compressed video over ATM networks with explicit rate feedback control”, Proceedings of IEEE Infocom’97, April 1997. [4] S. Mascolo, “Congestion control in high-speed communication networks using the Smith principle”, Automatica Journal, Special Issue on ‘Control Methods for Communication Networks’, Eds. J. Walrand and V. Anantharam, Dec. 1999. [5] M. Gerla, R. Lo Cigno, S. Mascolo, W. Weng, “Generalized window advertising for TCP congestion control”, CSD-TR 990012, UCLA, California, USA, Feb. 1999. [6] A. S. Tanenbaum, Computer Networks. Prentice Hall PTR, 3d edition, 1996. [7] M. Gerla, W. Weng, R. Lo Cigno, “BA-TCP: A bandwidth aware TCP for satellite networks”, Proceedings of IEEE ICCCN’99, Boston, Massachusetts, October 1999. [8] ns-2 Network Simulator. http://www-mash.cs.berkeley.edu/ns/, 1999. [9] R. Stevens, “TCP/IP Illustrated”, Vols. 1 & 2 Addison Wesley, 1994. [10] W. Stevens, “TCP slow start, congestion avoidance, fast retransmit, and fast recovery algorithms”, RFC 2001, IETF, Jan. 1997. [11] S. Floyd, V. Jacobson, “Random early detection gateways for congestion avoidance”, IEEE/ACM Transaction on Networking, Vol. 1, No. 4, pp. 397– 413, Aug. 1993. [12] T. V. Lakshman, U. Madhow, “The performance of TCP/IP for networks with high bandwidth-delay product and random loss,” IEEE/ACM Transactions on Networking, Vol.,5, No. 3, June 1997. [13] M. Gerla, R. Bagrodia, L. Zhang, K. Tang, L. Wang “TCP over wireless multihop protocols: simulation and experiments”, Proceedings of IEEE ICC’99, Vancouver, Canada, Jun. 1999. [14] H. Balakrishnan, N. Padmanabhan, S. Seshan, R. H. Katz, “A comparison of mechanism for improving TCP performance over wireless links”, IEEE/ACM Transaction on Networking, Dec. 1997.