当前位置：文档库 › TCP-friendly Congestion Control for Real-time Streaming Applications

TCP-friendly Congestion Control for Real-time Streaming Applications

MIT Technical Report,May2000. TCP-friendly Congestion Control for Real-time Streaming

Applications

Deepak Bansal and Hari Balakrishnan

https://www.wendangku.net/doc/123712203.html,boratory for Computer Science

Cambridge,MA02139

Email:bansal,hari@https://www.wendangku.net/doc/123712203.html,

Abstract

This paper introduces and analyzes a class of nonlinear con-gestion control algorithms called binomial algorithms,moti-vated in part by the needs of streaming audio and video ap-

plications for which a drastic reduction in transmission rate upon congestion is problematic.Binomial algorithms gen-eralize TCP-style additive-increase by increasing inversely

proportional to a power of the current window(for TCP, );they generalize TCP-style multiplicative-decrease by decreasing proportional to a power of the current win-

dow(for TCP,).We show that there are an in?nite number of deployable TCP-friendly binomial algorithms,all of which satisfy,and that all binomial algorithms converge to fairness under a synchronized-feedback assump-tion provided.Our simulation results show that binomial algorithms interact well with TCP across a RED gateway.We focus on two particular algorithms, IIAD(inverse-increase/additive-decrease,)and SQRT(),showing that they are well-suited to applications that do not react well to large TCP-style win-dow reductions.We also?nd that TCP-friendliness in terms of the relationship between throughput and loss rate of an al-gorithm does not necessarily imply fairness relative to TCP performance,especially for drop-tail bottleneck gateways.

1Introduction

The stability of the Internet to date has in large part been due to the congestion control and avoidance algorithms[15]im-plemented in its dominant transport protocol,TCP[28,34]. Based on the principle of additive-increase/multiplicative-decrease(AIMD)[6],a TCP connection probes for extra bandwidth by increasing its congestion window linearly with time,and on detecting congestion,reducing its window mul-tiplicatively by a factor of two.Under certain assumptions of synchronized feedback,Chiu and Jain have shown that an AIMD control scheme converges to a stable and fair operat-ing point[6],providing a sound basis for Jacobson’s algo-rithms found in most current TCP implementations[1].

TCP is not well-suited for several emerging applications such as streaming and real-time audio and video because the reliability and ordering semantics it ensures increases end-to-end delays and delay variations.To be safe for deploy-ment in the Internet,however,the protocols used by these applications must implement congestion control algorithms

that are stable and interact well with TCP.Such protocols

are called“TCP compatible”[3]or“TCP fair”.They ensure that the TCP connections using AIMD get their fair allo-

cation of bandwidth in the presence of these protocols and

vice versa.One notion that has been proposed to capture “TCP compatibility”is“TCP-friendliness”.It is well known

that the throughput of a?ow with TCP’s AIMD conges-

tion control(increase factor packet,decrease factor )is related to its loss rate as,where is the packet size[19,25,10,26].An algorithm is TCP-friendly[20]if its throughput with the same constant of proportionality as for a TCP connection with the

same packet size and round-trip time.

In this paper,we present and evaluate a new class of nonlinear congestion control algorithms for Internet trans-port protocols and applications.Our work is motivated by two important goals.First,we seek to develop and analyze a family of algorithms for applications such as Internet audio and video that do not react well to the large“factor-of-two”rate reductions that a TCP-style multiplicative-decrease en-tails,because of the drastic degradations in user-perceived quality that result.Second,we seek to achieve a deeper un-derstanding of TCP-compatible congestion control by gen-eralizing the class of linear control algorithms,and under-standing how a TCP-friendly algorithm competes with TCP for bottleneck resources.

An AIMD control algorithm may be expressed as:

D:(1) where refers to the increase in window as a result of re-ceipt of one window of acknowledgements in a RTT and refers to the decrease in window on detection of a loss by the sender,the window size at time,the round-trip time of the?ow,and and are constants.We have assumed a linear increase in window in the RTT.

To better understand the notions of TCP-friendliness and

the trade-offs between the increase and decrease rules,we

generalize the AIMD rules in the following way:

D:(2)

These rules generalize the class of linear controls.For ,we get AIMD;for,we get MIMD (multiplicative increase/multiplicative decrease used by slow start in TCP[15]);for,we get MIAD;and for we get AIAD,thereby covering the class of all linear controls.

We call this family of algorithms binomial congestion control algorithms,because their control expressions involve

the addition of two algebraic terms with different exponents. They are interesting because of their simplicity,and because they possess the property that any has a decrease that is in general less than a multiplicative decrease,a desir-able property for streaming and real-time audio and video. If there exist values of and(other than) for which binomial algorithms are TCP-friendly,then it pro-vides a spectrum of potentially safe congestion management mechanisms that are usable by Internet applications which do not react well to large and drastic rate reductions.It should be noted that varying and also help in reduc-ing the oscillations.However,they still keep the reduction multiplicative and as a result,the same value of and can-not be used across wide range of bandwidth*delay values by an application that desires an absolute bound on the inherent oscillations due to congestion control algorithm.For that purpose(for example,if the layers in layered media are ad-ditively spaced),and have to be made functions of cur-rent window values which is what binomial algorithms help achieve.

Our major?nding is that TCP-friendly binomial conges-tion control schemes do exist.Based on the analysis and simulation,we present the following?ndings:

The-relationship.For the binomial family of con-trols,.In particular,the linear control protocols MIMD and AIAD have,which is signi?cantly more aggressive than the AIMD TCP-compatible relationship,while MIAD is unstable.

The rule.A binomial algorithm is TCP-friendly if and only if and for suitable and.

This implies that there is a wide range of TCP-friendly binomial controls parametrized by and,and appli-cations can choose from this family depending on their needs and the level of rate degradation they can sus-tain.Furthermore,we show that under a synchronous feedback assumption,all the binomial control proto-cols converge to fairness as long as,and

.In particular,all the TCP-friendly binomial algorithms converge to fair allocations.

IIAD and SQRT control.Of this family,we evaluate two interesting TCP-friendly algorithms in the

space:and.We call the?rst IIAD(inverse-increase/additive decrease)be-cause its increase rule is inversely proportional to the current window,and the second SQRT because both its increase is inversely proportional and decrease propor-tional to the square-root of the current window.Our simulations show that both IIAD and SQRT interact

aggressive

TCP

Less

aggressive

Unstable

Region

SQRT

0.5

IIAD

MIMD

MIAD AIAD

AIMD

Unstable

Region

-1

friendly

Figure1.The)space of nonlinear controls from our family,with the line showing the set of TCP-compatible controls.

well with TCP AIMD across a wide range of network conditions over a RED bottleneck gateway.

TCP-friendliness vs.TCP compatibility.Over

a wide range of parameters,we discover that

TCP-friendliness does not necessarily imply TCP-compatibility.The unfairness stems from the buffer management algorithms implemented at a congested gateway and how buffers are sized at a drop-tail(FIFO) gateway.Fortunately,an active queue management scheme like Random Early Drop(RED)at the bottle-neck link alleviates this unfairness problem by explic-itly equalizing packet loss rates across?ows.Hence, while binomial algorithms are TCP-friendly(because they satisfy relationship,they become TCP-compatible in the presence of RED gateways.

Figure1summarizes the qualitative features of a bi-nomial algorithms in the space,including the points where it corresponds to the four linear controls,the line segment where it is TCP-friendly,and the regions where it is more and less aggressive than TCP AIMD.An in-teresting observation that follows from this?gure and our analysis is that of all the TCP-friendly binomial algorithms (),AIMD is most aggressive in prob-ing for available bandwidth.In this sense,AIMD is the most ef?cient and best suited binomial algorithm for bulk data transfer applications that can tolerate large reductions in available capacity upon encountering congestion.(Note that we assume that window size is always greater than1,so ).This observation shows the suitability of bino-mial algorithms as a good theoretical framework for evalu-ating additive increase/multiplicative decrease algorithms.

The rest of this paper is organized as follows.In Sec-tion2,we discuss and analyze the properties of binomial algorithms.In Section3,we delve into the IIAD and SQRT controls,presenting several simulation results with RED gateways and evaluating fairness with competing TCP con-nections.In Section4,we discuss the interactions between binomial algorithms and TCP in the presence of drop-tail gateways.We describe the performance results of our imple-

mentation of SQRT algorithm for an Internet audio applica-tion in Section5.We compare our work to past research on congestion management in Section7and conclude in Sec-tion8.

2Binomial congestion control algorithms

In this section,we present and analyze the properties of bi-nomial congestion control algorithms.We start by providing some intuition about the sample paths traversed by the con-gestion window in a binomial algorithm,and showing that it converges to fairness under simpli?ed conditions of syn-chronized feedback to sources.The intuition section makes simplifying assumptions but later,we corroborate our results by deriving an analytic formula that relates the throughput of a binomial algorithm to the loss rate it observes.We then, use this formula to obtain the conditions under which a bi-nomial algorithm is TCP-friendly.

2.1Intuition

We use the technique of Chiu and Jain and represent the two-source case as a“phase plot,”where the axes correspond to the current window sizes,,of each source(for conve-nience,we normalize each to a number between0and1, so it represents the fraction of the total window size aggre-gated across all competing sources).As the system evolves with time,the two sources adjust their windows according to the control equations,leading to a sample path in this phase space.The key to understanding binomial controls is to re-alize how these paths move in the phase space.To start with, we summarize how linear controls behave[6]:

1.Additive-increase/decrease:Moves parallel to the45-

line.Additive-increase improves fairness(in the sense of Jain’s fairness index1),additive-decrease reduces it.

2.Multiplicative-increase/decrease:Moves along the line

connecting to the origin.Fairness is un-changed.

Because binomial algorithms are non linear,their evolu-tion in the phase plot is not always along straight line seg-ments.Figure2shows a portion of one such sample path highlighting the increase and decrease parts.For all val-ues of,the increase in and are not equal—the smaller of the two values increases more than the larger one. It is clear that this leads to a fairer allocation than if both sources did additive-increase by the same constant amount. On the other hand,values of in the decrease phase worsen fairness.However,binomial algorithms still conver-gence to fairness as we show in Section2.2.

The parameters and represent the aggressiveness of probing and conservativeness of congestion response of a bi-nomial control algorithm.A small value for implies that the algorithm is more aggressive in probing for additional For a network with connections each with a share of a resource,the fairness index[16].bandwidth,while a large value of implies that the algorithm displays large window reductions on encountering conges-

tion.Thus,it would seem that there is a trade-off between and in order for for a binomial protocol to achieve a certain throughput at some loss rate.

Indeed,in Section2.3,we show that at any loss rate,the throughput depends on the sum of the two exponents,. As a corollary,we?nd that a binomial algorithm is TCP-

friendly if and only if and.We call this the rule,which represents a fundamental tradeoff between probing aggressiveness and the responsiveness of window

reduction.Figure1shows the features of the space. We consider schemes for which as unstable(Figure1), since there always exists a window size(assuming

)above which for any constant.It can be made stable by having it not cut down window by an amount more than the current window but that involves modifying the basic increase decrease rules and thus,we consider them unstable.Similarly,schemes for which are also unstable because as rule will show,does not decrease with increasing in this realm.As a result,the window for a connection will keep on increasing(or remain same)as loss rate is increased.

2.2Convergence to fairness

In this section,we show that a network with two sources implementing the same binomial control algorithm with converge to a fair and ef?cient operating point (),provided that.The argument is easily extended to a network of sources by consid-ering them pairwise.We assume that the network provides synchronized feedback about congestion to all the sources2. We do not claim that this models the reality of Internet con-gestion well,but this analysis provides good insight into the results that follow.

Without loss of generality,suppose,which cor-responds to points above the equi-fairness line in Figure2(an analogous argument can be made when ).First,consider the left-most picture that shows how a window increase evolves.When,the increase is additive,parallel to the45-line(along line AB).When ,the increase curve lies below the line since the amount of increase in is larger than the corresponding increase in(note).Therefore,it intersects the maximum-utilization line at a point C,to the right of where the line intersects it.Such an increase improves ef?ciency,since increases,and moves to-wards a fairer allocation(i.e.,towards the intersection of the equi-fairness and maximum-utilization lines).

Now,consider a window reduction.Observe that when (additive decrease),the window reduction occurs along the45line(along line DE),worsening fairness. When,the decrease is multiplicative and moves along the line to the origin without altering fairness.For ,the window reduction occurs along a curve with This is the same network model as in Chiu and Jain’s work[6].

k=-1

k=0k>0

k>0

Maximum Utilization Equi-fairness line

line (MUL)

Point of intersection with MUL shifts right on each cycle (see 45 lines as reference)

l =0=1

l l l x2

0<0<<1

F D B C

Figure 2.Sample path showing the convergence to fairness for an inverse increase proportional decrease algorithm.

shape as shown in the middle picture of Figure 2;this curve is in-between the previous two lines (and lines)and causes the system to evolve to an under-utilized region of the curve where .This curve lies strictly

below the

line because the tangent at each point has a slope =when .Therefore,it intersects the maximum-utilization line at a point F which is closer to the fair allocation point relative to the previous intersection of the sample path with that line.

The key to the convergence argument is to observe that the successive points of intersection of a binomial curve with the maximum-utilization line always progress

toward the fair allocation point.When

,this con-tinually moves downwards,when

,it continually moves upwards towards the point.Once ,a binomial algorithm behaves exactly like a linear algorithm,

moving on the

equi-fairness line.It is easy to see that all we require in the above argu-ment is for at least one of and to be larger than zero,since the sample path needs to move to the right at some stage.When ,the algorithm is the linear additive-increase/additive-decrease scheme,which does not converge.The window evolution here remains on the 45-line passing through any point ,without moving to-ward the fair allocation point.

This proof is valid under the synchronized feedback as-sumption and shows that a network in which all sources im-plement the same binomial control algorithm converges to a fair operating point.We note that it does not address the case of different binomial algorithms coexisting in the same network.

2.3Throughput

We now analyze the throughput of a binomial algorithm as a function of the loss rate it experiences.We start with the steady-state model studied for TCP by Lakshman and Madhow [18]and Floyd [10].Using the increase rule of Equation 2,we get using a continuous ?uid

approximation

Figure 3.Functional form of window vs time curve.

and linear interpolation of the window between

and

(3)

where is an integration constant.

The functional form of this curve is shown in Figure 3.We are interested in two parameters marked in the ?gure:,the time between two successive packet drops,and ,the number of packets between two successive drops.Both these are independent of “time-shifting ”the curve along the horizontal (time)axis,which implies that one can arrange it such that a downward extrapolation of the curve passes through the origin.That is,without loss of generality and with no change to and ,one can set .

Let

be the maximum value of the window at time (Figure 3),at which a packet drop occurs signifying con-gestion to the sender.Then,one can write expressions for

and as follows:

Substituting and in Equation 3,we get

(when and)(4) The leading term in therefore varies as,with the succeeding terms becoming increasingly insigni?cant.

is the shaded area under the curve in Figure3.

(5) Calculating the integral,we get:

(leading term)

(6) The average throughput(in packets per second),of a?ow using binomial congestion control is the number of packets sent in each epoch between successive drops()divided by the duration between drops().The packet loss prob-ability,.Writing and in terms of by substituting the expressions for and yields:

(7)

Thus,for a protocol in this family.This implies that for such a protocol to be TCP-friendly,must vary as,which implies that:

(8)

To?rst order,choosing to be the same as for TCP would achieve similar performance.Note that in our analy-sis above we have assumed a linear interpolation of window between and i.e we assume an increase in window by one in a RTT for TCP rather than an increase by1/w on receipt of each acknowledgement.

These results also hold for the random-loss model?rst analyzed by Ott et al.in the context of TCP[25].Un-like in the steady-state model where losses happen period-ically when the sender’s window reaches,losses in the random-loss model are modeled as Bernoulli trials where each packet is independently lost with probability.

We use the stochastic approximation technique for TCP performance described by Wang and Schwartz[36].We treat the window value after receiving an acknowledgment with sequence number,,as a stochastic process and cal-culate its average value in the steady state.If we run the algorithm for a long time,the resulting congestion proba-bility(the number of window reductions over the number of packets sent)is.Then,in the steady state,the random process evolves as follows:given,with probability ,the packet is not lost and the sender’s window in-creases,so,whereas with probability ,the packet is lost,forcing the window to reduce giving

Using this,we can calculate the average“drift”in the window when.. Assuming that the stochastic process has a stationary distribution,must have most of its probability around the region for such that.Thus:

(9)

if(10)

We emphasize that is the per-packet loss probability.As shown in the steady-state analysis above,is a good approximation to the time average of the random process. The result,that

therefore follows for the random-loss model as well.

This relationship establishes the fact that for a given loss rate and identical conditions,TCP AIMD and a binomial al-gorithm satisfying rule can achieve the same through-put.Further,it shows that for a given loss rate,two bi-nomial connections will achieve same throughput provided other conditions are same.

3Simulation results

In this section,we present the results of our ns-2[24]simu-lations of binomial control algorithms.We start by investi-gating the interactions between connections running a TCP-friendly binomial control algorithm(i.e.,one that satis?es the rule)and TCP,as a function of,which deter-mines how aggressive the window increase factor is.We then investigate the performance of two speci?c members of this family:IIAD(inverse-increase/additive-decrease;

)and SQRT(;this corresponds to an increase proportional to the square-root of the current win-dow and a decrease proportional to it).We conclude this section by studying the performance of IIAD and SQRT in the presence of multiple bottlenecks.

Our single bottleneck simulations used the topology shown in Figure4.It consists of connections sharing a bottleneck link with total bandwidth equal to;all connec-tions have an identical round-trip propagation delay equal

Figure4.Simulation topology(delays of links for which no

delay is speci?ed are all equal such that the round-trip time for each connection=ms).

to(we change and in various simulations). We implemented the transport protocol by modifying the

congestion avoidance algorithm used by TCP;we replaced

AIMD with the binomial family.However,we did not mod-ify the connection start-up or timeout routines;they continue

to use slow-start and timeouts as before.Thus,the effect of

slow start and timeouts on connection throughput is same as for a normal TCP connection.Each source always has data

to send,modeled using ns’s“FTP”application.In all our

experiments,we simulated each topology and workload ten times and calculated both the average and sample standard

deviation of the observed values.The?gures and graphs

display this information.

In this section,we present performance results using

Floyd and Jacobson’s Random Early Drop(RED)buffer

management algorithm at the bottleneck gateway[12].The

maximum queue size at the bottleneck was set to, the bandwidth-delay product of the path.The minimum and

maximum drop thresholds(and)were set to and respectively,and the connections used a packet size of1KByte.Each connection was started at uni-

formly chosen random times in seconds and through-

put was calculated from to to give suf?cient time for the connections to stabilize and to?lter out startup https://www.wendangku.net/doc/123712203.html,ter in the section,we also present results show-ing startup effects and impulse response of a binomial algo-rithm on TCP and vice versa.

3.1TCP-compatibility

Our?rst set of results(Figure5)show how binomial al-gorithms interact with each other and with TCP.To study the effect of and on TCP,we simulated two connec-tions(),one TCP and the other a binomial algorithm parametrized by.We show three sets of results correspond-ing to the three cases equal to,less than,and greater than.For these simple scenarios,these results validate the rule for TCP-friendliness,since the long-term through-put for the binomial algorithms for which are close

0.5

1.5

00.20.40.60.81 1.2 1.4

Fairness to TCP vs k for k+l=1

Fairness to TCP vs k for k+l=0.5

Fairness to TCP vs k for k+l=1.5

Figure5.Ratio of the throughput of TCP AIMD to the throughput of a binomial algorithm,as a function of.The algorithms that satisfy the rule are the ones for which this ratio is closest to unity.When,the binomial algorithm obtains much higher throughput relative to TCP and when,TCP obtains much higher through-put relative to binomial algorithm,as predicted by the anal-ysis.The error bars show the95%con?dence interval of the throughput ratio.In these experiments,Mbps and ms.

to that of TCP.These results also show that TCP-friendliness implies TCP-compatibility across RED gateways.

3.2IIAD Algorithm

We now turn to IIAD,which is relatively less aggressive in the rate at which it probes for bandwidth(),but at the same time only reduces its window by a constant upon con-gestion().We choose the values of and such that the theoretical throughput of IIAD is close to the through-put of TCP AIMD.There are an in?nite number of val-ues for and corresponding to this;we pick one pair,

We compare the fairness of IIAD relative to another IIAD instance and to a TCP/Reno sharing the same bottle-neck using the topology and workload in Figure4.In these experiments,and each connection was started at a random time in seconds.Each individual experiment was conducted using a bottleneck bandwidth of1.5Mbps and the round-trip time was varied between50ms and 200ms.

Figure6plots the throughput ratio for two IIAD connec-tions on one curve and for one IIAD and one TCP connec-tion on the other curve.These results show that IIAD is fair to both the IIAD and to TCP across a range of val-ues.However,the standard deviation of the results increases as increases.This is because as increases,each connection takes a greater amount of time to reach the op-timum available bandwidth.Furthermore,when persistent losses occur leading to a timeout(recall that these experi-

0.5

1.5

406080

100120140160

R a t i o o f t h r o u g h p u t s

RTT(ms)

IIAD conn throughput/another IIAD conn. thruput

TCP conn throughput/IIAD conn. thruput

Figure 6.Ratio of throughputs of two connections sharing the bottleneck along with 95%con ?dence intervals (

Mbps).

ments use a modi ?ed TCP source and sink),the congestion window shrinks to one packet and slow start occurs.The ini-tial start-up effects and response to timeouts take longer to stabilize at higher delays,resulting in the correspondingly higher variance.The start-up effects are exacerbated for IIAD because it is less aggressive than AIMD,and responds relatively slower to any spare bandwidth.This is the reason that at higher delays,IIAD sometimes loses to TCP;the con-nections experience losses during slow start and IIAD takes longer to ramp to its share of bandwidth.Figure 6shows that IIAD and TCP AIMD are fair to each other over long time scales.We observed the same results and behavior across a range of bottleneck bandwidths.

5101520253035

45500510

152025

W i n d o w (p a c k e t s )

Time (sec)

IILD conn 1IILD conn. 2

Figure 7.Congestion window evolution at the sender for two IIAD connections that start at random times in sec-onds.In this experiment,

Mbps and ms.For one of these experiments,we look at the evolution of the congestion window.Figure 7shows this for the two IIAD connections,showing the expected increase and de-0

05101520

IIAD AIMD

Figure 8.Congestion window variation for the IIAD and TCP Reno connections started at random times.

crease behavior as a function of time.For want of space,we do not show the sequence trace for these two connec-tions here,but the two connections quickly achieve the same slopes signifying that they share bandwidth well with each other.We observed such good sharing across a range of and values.

More interesting is the interaction between IIAD and TCP in terms of the evolution of their congestion windows (Figure 8).We observe that the window values quickly be-come similar,and even though the TCP connection started later,it was able to obtain its share of bandwidth without any dif ?culty.

51015202530

35404505101520

253035404550

W i n d o w (p a c k e t s )

time(sec)

IILD conn. 1IILD conn. 2

Figure 9.Slow start response of an IIAD ?ow to another

long-running IIAD ?ow.In this experiment,

1.5Mbps,50ms.

We now consider the impulse-response behavior of the binomial control algorithms.Our experiences with these experiments across several binomial algorithms have con-vinced us that slow start (or a similar mechanism)is an im-portant component of any practical protocol to ensure that a

connection converges relatively quickly,within a few s to the fair value.We show an example of this in Figure 9,which shows how slow start enables a new IIAD connection to catch up and share bandwidth with another long-running IIAD connection.

7080

05101520

253035404550

W i n d o w (p a c k e t s )

time(sec)

TCP conn.IILD conn.

Figure 10.Response of a long-lived IIAD ?ow to a TCP

impulse.In this experiment,

1.5Mbps and 50ms.

51015202530

354045051015

2025303540

W i n d o w (p a c k e t s )

time(sec)

TCP long lived IILD impulse

Figure 11.Response of a long-lived TCP ?ow to an IIAD

impulse.In this experiment,

Mbps and ms.

We observe the same behavior when a new TCP AIMD connection impulse encounters a long-running IIAD,as shown in Figure 10.The results of the converse experiment are shown in Figure 11,where an IIAD impulse meets a long-lived TCP AIMD.These ?gures show that IIAD and TCP converge to their fair bandwidth share,with the im-pulses using slow start.

These results hold when the number of connections is increased as well.Figure 12shows the window variation for ?ve of ?fteen concurrent IIAD ?ows sharing the bottleneck link.At time seconds,a TCP AIMD connection starts

100

150

200

250

051015

2025303540

W i n d o w (p a c k e t s )

time (sec)

IIAD conn 1IIAD conn 2IIAD conn 3IIAD conn 4IIAD conn 5TCP/Reno conn

Figure 12.A TCP AIMD connection grabs its fair share in the presence of many long-lived IIAD ?ows (Mbps ms).For clarity,we only show the win-dow sizes of ?ve IIAD connections and the TCP connection.

(the impulse at

),and is able to grab its share of band-width even in the presence of several other long-lived IIAD connections as can be seen from the TCP window evolution after about seconds.Conversely,Figure 13shows the window evolution of an IIAD ?ow that starts at time

seconds in the presence of ?ve concurrent long-lived TCP connections (for clarity,we only plot the windows of two of the TCPs).

3.3SQRT algorithm results

We now investigate the performance of the SQRT algorithm,which has .

Although we use

and in the reported ex-periments;we found that performance is relatively insensi-tive to small changes in .We do not report the results of all the experiments we conducted with SQRT;in particular,we found that the long-term fairness of SQRT connections with each other and with TCP are high.We obtained results very similar to Figure 6(the IIAD experiments),across a wide range of and values,showing that when the number of connections is small,SQRT connections share bandwidth fairly with each other and with TCP AIMD.

SQRT differs from IIAD in its aggressiveness in increas-ing its window and in reducing its window upon congestion.As a result,the details of its interaction with TCP AIMD are different from those of IIAD.This is shown in Figure 14,where a TCP impulse encounters a long-running SQRT con-nection at the bottleneck.We see that the two connections converge to their share of the bandwidth in fewer number of round-trip times than in the TCP-IIAD case (Figure 10).Figure 15plots the time evolution of the congestion win-dow for concurrent SQRT and AIMD connections.As ex-pected,the window variations for SQRT are larger than for IIAD (Figure 8),but its variations are markedly smaller than TCP.As with IIAD,this does not affect bandwidth sharing

020406080

100120140

160

2025

W i n d o w (p a c k e t s )

time (sec)

TCP conn 1TCP conn 2IIAD conn

Figure 13.An IIAD ?ow grabs its fair allocation in the presence of many long-lived TCP ?ows (Mbps ms).For clarity,we only show the win-dow sizes of two TCP connections and the IIAD connection.

05101520

253035404550

W i n d o w (p a c k e t s )

time(sec)

TCP conn.

IILD conn.

Figure 14.Response of a long-lived SQRT ?ow to a TCP impulse.In this experiment,Mbps and ms.

as can be seen from the window plot.We observed similar results for a range of and values,and when we scaled to higher values.

Finally,we consider the sensitivity of our results to the value of in the binomial algorithms by showing our re-sults for SQRT case (we obtained similar results for IIAD as well).Figure 16plots the effect of on fairness to a TCP connection sharing the bottleneck.We observe little varia-tion in the throughput ratio,but notice that fairness to TCP reduces at the extremes.When is close to 0,TCP AIMD loses and when is close to 1,SQRT loses.This is expected behavior based on the magnitude of SQRT window reduc-tion upon congestion.

101520

W i n d o w (p a c k e t s )

time(sec)

AIMD alg SQRT alg

Figure 15.Graph showing window variation for SQRT

and TCP AIMD connections sharing the bottleneck (Mbps ms).

3.4Multiple connections and multiple bottle-necks

This section investigates the impact of scale on binomial al-gorithms along two dimensions:(i)increasing the number of concurrent connections across a single bottleneck,and (ii)investigating performance across multiple bottleneck links.To understand how several connections using different TCP-friendly binomial algorithms interact with each other,our ?rst series of experiments looks at several concurrent connections running different algorithms sharing the bottle-neck.The topology we use is same as in Figure 4with

Mbps and ms.We choose values of

and ,and vary the total

number of connections .For each value of ,we set up connections,and start each connection at a random time in the interval seconds.In Figure 17,we plot the mean value of Jain ’s fairness index (ten runs for each data point)along with 95%con ?dence intervals.

To study the impact of multiple bottlenecks and back-ground traf ?c on the performance and fairness of binomial algorithms,we simulated the topology shown in Figure 18.The maximum number of HTTP connections for each HTTP source was set to ?ve and all other parameters were set to the default values from ns-2for the HTTP and CBR sources and sinks.The window variation for the TCP AIMD and IIAD sources are shown in ?gure 19.As can be seen from this ?gure,the bottleneck bandwidth gets distributed fairly among these sources even in the presence of multiple bottle-necks.We observed the same behavior for other sources in this simulation and also when we replaced the IIAD source a SQRT source.

4TCP friendliness vs TCP Compatibility

In this section,we study the interactions between binomial algorithms and TCP AIMD over a drop-tail bottleneck gate-

00.2

0.4

0.6

0.8

1.2

1.4

0.2

0.4

0.6

0.8

1.2

T C P T h r o u g h p u t /S Q R T T h r o u g h p u t

beta parameter

Beta Sensitivity

Figure 16.Plot showing fairness of SQRT to TCP/Reno (throughput ratio)along with the 95%con ?dence-interval for various values of of the SQRT algorithm (Mbps,

ms).

way,observing some surprising effects.Figure 20shows the window variation and bottleneck buffer occupancy for two connections,one TCP AIMD and the other IIAD,sharing a drop-tail bottleneck gateway.We see that TCP starts losing out and its window keeps on decreasing until it starts to os-cillate below its fair share because no buffers are available to it.On the other hand,IIAD starts grabbing more and more bandwidth.We observed similar behavior with other bino-mial algorithms as well.

At ?rst,we found this result puzzling because the theory and the rule had predicted that as long as ,the long-term throughput of a binomial algorithm would be equal to TCP AIMD.However,closer examination of the bottleneck buffer occupancy revealed the problem.In a con-gested network,the “steady state ”of the bottleneck queue is close to full.IIAD is less aggressive than AIMD,and when it reduces its window,does not completely ?ush the queue.When a drop-tail gateway has been con ?gured with a queue size of ,it ensures that TCP-style “factor-of-two ”multiplicative decrease brings the reducing connec-tion ’s contribution to the bottleneck occupancy down to (or close to)0.This allows other competing connections to ramp up and also ensures that suf ?cient buffers are available for the window to increase before another “factor-of-two ”re-duction happens.In contrast,a non-AIMD TCP-friendly bi-nomial algorithm,by its very design,ensures that window reductions are not drastic.As a result,it ends up with more than its fair share of the bottleneck;and a window reduc-tion does not ?ush all of its packets from the queue.In fact,the competing AIMD window oscillates as if it sees buffers equal to the additive decrease term (the amount of buffer freed by IIAD on a reduction)of the IIAD algorithm.The result is that drop rates observed by the two ?ows competing at a drop-tail bottleneck are not equal.This argument also shows how buffer provisioning is intimately tied to the win-dow adjustment algorithm of the end-systems for drop-tail

0.2

0.4

0.6

0.8

1.2

0510

1520

253035

J a i n ’s F a i r n e s s I n d e x

Number (n) of connections

Mixture of TCP-compatible algorithms

Figure 17.Plot showing Jain ’s Fairness Index as a func-tion of the number of TCP-compatible connections sharing a bottleneck.In each experiment,the total number of connec-tions was divided equally into ?ve categories corresponding to

.In these experiments,Mbps,ms.The (tiny)error-bars show 95%con-?dence intervals.

HTTP Src2

CBR Src1

Figure 18.Topology with multiple bottlenecks and back-ground traf ?c.

gateways.

In contrast,RED gateways are designed to accommodate bursts and maintain small average queue sizes by providing early congestion indications.They seem ideally suited to binomial algorithms because they do not tie buffer sizing closely to the precise details of window adjustment of the end-points.Instead they vary the drop rate as a function of queue size making all ?ows see the same drop rate.This is yet another among the many other compelling reasons for the Internet infrastructure to move to a more active queue management scheme like RED.

We do not view the TCP-unfairness of the binomial algo-rithms across drop-tail gateways as a deployment problem:?rst,the binomial algorithms obtain better throughput than TCP AIMD with drop-tail gateways,which augurs well for applications using them (and also provide an incentive for Internet Service Providers to move to better queue manage-ment schemes)!Second,any scalable scheme for detecting ?ows using more than their share of bandwidth would likely

100

150

200

250

300

0510

202530

W i n d o w (i n p a c k e t s )

time (in sec)

TCP/Reno

IIAD

Figure 19.Window variation vs.time for the topology with multiple bottlenecks.

1015

W i n d o w /Q u e u e S i z e

time(sec)

TCP

IIAD

Queue Size

Figure 20.Plot showing window/queue size variation for TCP/Reno and SQRT algorithms sharing the bottleneck with

drop-tail gateways(

Mbps,ms).use an active queue management scheme and not a drop-tail gateway,which would ensure that true fairness to TCP is achieved.We emphasize that the adverse interactions of the binomial algorithms with TCP are primarily a consequence of the ill effects of drop-tail queue management.

An important consequence of the above ?ndings and ar-guments is that TCP-friendliness does not necessarily imply TCP-compatibility since the theory assumes that drop rates for competing ?ows are equal at a gateway.We therefore conclude that justifying a congestion control algorithm as safe for deployment on the Internet purely on the basis of the TCP-friendly equation is dangerous.While our experience indicates that this is reasonable with certain types of queue management (such as RED),it is incorrect when congestion occurs at a drop-tail gateway.We believe that deriving a set of suf ?cient conditions for TCP-fair congestion control in drop-tail networks requires further research.

5000

10000

15000

20000

1500020000

2500030000

3500040000

C o n g e s t i o n W i n d o w

Kernel Time (in units of 10ms)

VAT using SQRT cong ctrl

Figure 21.Window variation for a vat session using SQRT congestion control with a bottleneck con ?gured using Dum-mynet (Kbps,ms).

20004000600080001000012000

14000

16000

180003.155e+06

3.16e+06 3.165e+06

3.17e+06 3.175e+06 3.18e+06 3.185e+06 3.19e+06

C o n g e s t i o n W i n d o w

Kernel Time (in units of 10ms)

VAT using SQRT cong ctrl

Figure 22.Window variation for a vat session using SQRT

congestion control across an Internet path.

5Implementation

We have implemented the SQRT congestion control algo-rithm in the Linux Kernel (version 2.2.9)to provide con-gestion controlled UDP sockets.We experimented with the Internet audio conferencing tool,vat in unicast mode.Fig-ure 21shows the congestion window variation for a transfer as a function of 10ms time intervals for an audio session be-tween two Linux machines.These machines were on the same LAN but had a pipe of bandwidth 50Kbit/s and

900ms between them,con ?gured using Dummynet [8].The ?gure shows the effectiveness of SQRT congestion control in alleviating the large TCP-style “factor-of-two ”reductions.The magnitude of oscillations are smaller than what AIMD would observe.

Figure 22shows the congestion window variation for a vat transfer between two Linux machines,one at MIT and the other at University of California,Berkeley.Again,the

magnitude of oscillations are much smaller than with AIMD. The window keeps increasing because the bandwidth avail-able between these two machines was much higher than the 64Kbps,rate at which vat samples audio data.This graph also demonstrates the working of SQRT across the Internet, since the occasional reductions are not drastic.

We note that our algorithms can be incorporated in the Congestion Manager(CM)architecture to provide applica-tions tunable congestion control[2].The CM exports an API that allows applications to learn about and adapt to the net-work conditions;this API can easily be extended to allow an application to pick the parameter()of a binomial algo-rithm,with the CM using the rule to ensure that the choice is TCP-friendly.An audio or video application can then,easily use one of the TCP-friendly binomial algorithms over a UDP-based transport protocol.While it is unlikely that elastic applications that run well over TCP today will use a non-AIMD binomial algorithm,an implementor can change the TCP sender with little implementation effort.

In fact,a protocol may switch between different TCP-friendly binomial algorithms in real-time,adapting to chang-ing network conditions.In particular,it can probe more ag-gressively if it observes no congestion for a while,and probe less aggressively otherwise.

6Deployment of Binomial Controls in the In-ternet

An issue of concern for wide scale deployment of IIAD algo-rithms in the Internet may be that their relatively mild reduc-tion in window on experiencing congestion may affect Inter-net stability.However,we believe that the primary threat to the Internet stability comes not from the?ows using some form of TCP-compatible congestion control but from?ows that do not use any congestion control at all.Moreover,pre-vention of congestion collapse does not require that?ows reduce their sending rate by half in response to a single con-gestion indication.The binomial algorithms,being window based and TCP-friendly,cannot cause congestion collapse simply by the fact that they send out data only in response to receipt of successful acknowledgements(except during timeouts)at the receiver.Moreover,in response to even a single loss,these algorithms reduce their window and hence alleviate congestion by stopping data transmission till the network acknowledges(or delivers)suf?cient data(equal to cutdown)after that loss.

Another issue may be that and values of TCP’s AIMD can be adjusted to provide a more stable congestion control as against using binomial controls.As mentioned earlier,adjusting and can only provide relative and not absolute(or?xed)bounds on oscillations due to congestion control.Moreover,binomial controls provide a framework for studying window based congestion control for multime-dia applications of which TCP AIMD is one possibility.7Related work

There has been signi?cant work over the past?fteen years in the area of network congestion management,especially on end-system mechanisms.

Chiu and Jain analyze the performance of linear controls, deriving the conditions for ef?cient convergence to fairness under a synchronized-feedback assumption[6].They allude to non-linear controls and brie?y discuss some of their prop-erties,concluding that they seem more complex and inferior to linear controls.To our knowledge,a thorough analysis and evaluation of any family of nonlinear congestion control algorithms has not been done until now.We also focus on TCP-compatibility,recognizing the large deployed base of TCP AIMD algorithms.

Much of the classical literature on end-system conges-tion management was motivated primarily by reliable uni-cast transport,and included both window-and rate-based approaches.In addition to Jacobson’s TCP algorithms[15], prominent examples and studies include Ramakrishnan and Jain’s DECBit scheme that was linear with a multiplicative-decrease factor()of,rate-based control in the Ver-satile Message Transport Protocol(VMTP)[5],Clark et al.’s NETBLT[7],Keshav’s packet-pair approach(which re-quires?ow isolation at congested routers)[17],and Faber et al.’s Dynamic Time Windows[9].

Subsequent to the development and deployment of TCP’s algorithms in the Internet,Wang and Crowcroft pro-posed“Tri-S”(slow start and search)[37]to improve TCP’s slow start.Brakmo and Peterson proposed TCP Vegas[4], which attempted to improve TCP’s congestion avoidance and loss recovery.More recently,a number of enhance-ments have been proposed to TCP congestion control,in-cluding the persistent fast recovery of Newreno[14],selec-tive acknowledgments(SACK)[22],and forward acknowl-edgments(FACK)[21].RFC2581describes the recom-mended algorithms for proper congestion control in TCP[1].

[13]has formulated congestion control as a global optimiza-tion problem and has proposed a class of congestion control policies based on rewards and costs.

While these TCP enhancements are interesting,signif-icant recent trends in Internet applications and traf?c have led to a renewed interest in in end-system congestion con-trol protocols.Several emerging applications including uni-cast audio and video are best transported over an application-level protocol running over UDP,rather than over TCP be-cause they do not require a fully-reliable in-order deliv-ery https://www.wendangku.net/doc/123712203.html,ing TCP leads to a large delay varia-tion caused by retransmissions,and perceptual quality shows sudden degradations in the face of a TCP-style window re-duction for these applications.

Much recent work has focused on congestion control for adaptive applications.Rejaie et al.’s Rate Adaptation Pro-tocol(RAP)uses AIMD,relying on frequent receiver ac-knowledgments to adjust the sender’s rate[31].They also propose a quality adaptation algorithm for discretely-layered streams at the receiver to handle the rate variations trig-gered by AIMD[30].In the context of multicast,McCanne

et al.’s receiver-driven layered multicast(RLM)incorpo-rates a probing and rate reduction mechanism for layered video[23].Sisalem and Schulzrinne’s Loss-Delay-based Adjustment(LDA)scheme uses an AIMD rate control at the sender,using RTCP[32]for feedback[33].Schemes like RAP and LDA can use a binomial algorithm(e.g.,IIAD or SQRT)to avoid drastic rate reductions on encountering con-gestion.

To combat the ill-effects of multiplicative decrease on a single packet loss,various researchers have been look-ing at the class of“equation-based control algorithms”[20, 27,35].These are schemes where the sender measures the packet loss rate and round-trip time over some past time and uses these estimates to determine a TCP-compatible trans-mission rate based on an equation relating TCP throughput to the loss rate[26].The effectiveness of such schemes depends critically on the method used to estimate loss rate[29,11].It will be interesting to compare binomial al-gorithms with equation-based control.

8Concluding remarks

In this paper we presented and evaluated a new family of nonlinear congestion management algorithms,called bino-mial algorithms.They generalize the familiar class of linear algorithms;during the increase phase,

and on experiencing a loss,.We showed that a network with sources running the same binomial algo-rithm converges to fairness under a synchronized-feedback assumption if and at least one of or is positive,and that the throughput of a binomial algorithm

,where is the loss rate it encounters.As a corollary,a binomial algorithm is TCP-friendly if and only if and(the rule).

The rule represents a fundamental trade-off between probing aggressiveness and congestion responsiveness,with small values of being less drastic in window reduction. Hence,we believe that binomial algorithms with are well-suited to applications like audio and video that do not react well to drastic multiplicative decrease.Our preliminary experiments seem to justify this hypothesis,although more validation and research is needed before widespread deploy-ment can be recommended.For applications that simply want to transmit as much data as quickly as they can without worrying about the degree of rate variations while doing so, the rule shows that AIMD is a very good strategy.Of all the TCP-friendly binomial algorithms,AIMD is the most ef?cient in aggressively probing for bandwidth.

Our simulation results showed good performance and interactions between binomial algorithms and TCP,espe-cially using RED.We also found that TCP-friendliness does not necessarily imply TCP-compatibility in a network with drop-tail gateways—a binomial algorithm like IIAD or SQRT obtains higher long-term throughput than TCP be-cause of a higher average buffer occupancy.Active queue management schemes like RED allow binomial algorithms and TCP to interact well with each other,which may be viewed as another among many important reasons to elimi-nate drop-tail gateways from the Internet infrastructure.

We believe that the results presented in this paper lead to a deeper understanding of the issues involved in the increase and decrease phases of a congestion management algorithm and in the notions of TCP-friendliness and TCP-fairness.We hope that our?ndings will spur further research into conges-tion control dynamics to obtain a fundamental understand-ing of a future Internet with multiple coexisting congestion control algorithms and protocols. Acknowledgments

This work was supported by research grants from the NTT Corporation,DARPA(Grant No.MDA972-99-1-0014),and IBM Corporation.We thank David Andersen,John By-ers,Dah Ming Chiu,David Clark,Sally Floyd,Allen Miu, Srinivasan Seshan,Alex Snoeren,and Roshni Srinivasan for helpful comments on earlier drafts of this paper. References

[1]A LLMAN,M.,AND P AXSON,V.TCP Congestion Control.

Internet Engineering Task Force,April1999.RFC2581.

[2]B ALAKRISHNAN,H.,R AHUL,H.S.,AND S ESHAN,S.An

Integrated Congestion Management Architecture for Internet Hosts.In Proc.ACM SIGCOMM(Sep1999).

[3]B RADEN,B.,C LARK,D.,C ROWCROFT,J.,D AVIE,B.,

D EERING,S.,

E STRIN,D.,

F LOYD,S.,J ACOBSON,V.,

M INSHALL,G.,P ARTRIDGE, C.,P ETERSON,L.,R A-MAKRISHNAN,K.,S HENKER,S.,W ROCLAWSKI,J.,AND Z HANG,L.Recommendations on Queue Management and Congestion Avoidance in the Internet.Internet Engineering Task Force,Apr1998.RFC2309.

[4]B RAKMO,L.S.,O’M ALLEY,S.W.,AND P ETERSON,L.L.

TCP Vegas:New Techniques for Congestion Detection and Avoidance.In Proc.ACM SIGCOMM’94(Aug.1994). [5]C HERITON,D.,AND W ILLIAMSON,C.VMTP as the Trans-

port Layer for High-Performance Distributed Systems.IEEE Commun.Mag.(June1989),37–44.

[6]C HIU,D.-M.,AND J AIN,R.Analysis of the Increase and

Decrease Algorithms for Congestion Avoidance in Computer https://www.wendangku.net/doc/123712203.html,puter Networks and ISDN Systems17(1989), 1–14.

[7]C LARK,D.,L AMBERT,M.L.,AND Z HANG,https://www.wendangku.net/doc/123712203.html,BLT:

A High Throughput Transport Protocol.In Proc.ACM SIG-

COMM(Aug.1988).

[8]Dummynet.

,Sept.1998.

[9]F ABER,T.,L ANDWEBER,L.,AND M UKHERJEE,A.Dy-

namic Time Windows:Packet Admission Control with Feed-back.In Proc.ACM SIGCOMM(1992).

[10]F LOYD,S.,AND F ALL,K.Promoting the Use of End-to-

End Congestion Control in the Internet.IEEE/ACM Trans.on Networking7,4(Aug.1999).

[11]F LOYD,S.,H ANDLEY,M.,P ADHYE,J.,AND W IDMER,

J.Equation-Based Congestion Control for Unicast Applica-tions.,June2000. [12]F LOYD,S.,AND J ACOBSON,V.Random Early Detection

Gateways for Congestion Avoidance.IEEE/ACM Transac-tions on Networking1,4(Aug.1993).

[13]G OLESTANI,S.J.,AND S.,B.A Class of End-to-End Con-

gestion Control Algorithms for the Interney.In Proc.ICNP (1998).

[14]H OE,J.C.Improving the Start-up Behavior of a Conges-

tion Control Scheme for TCP.In Proc.ACM SIGCOMM’96 (Aug.1996).

[15]J ACOBSON,V.Congestion Avoidance and Control.In Proc.

ACM SIGCOMM(Aug1988).

[16]J AIN,R.The Art of Computer Systems Performance Analysis.

John Wiley and Sons,1991.

[17]K ESHAV,S.Packet-Pair Flow Control.IEEE/ACM Transac-

tions on Networking(Feb.1995).

[18]L AKSHMAN,T.V.,AND M ADHOW,U.The Performance of

TCP/IP for Networks with High Bandwidth-Delay Products and Random Loss.IEEE/ACM Trans.on Networking5,3 (1997).

[19]L AKSHMAN,T.V.,M ADHOW,U.,AND S UTER, B.

Window-based Error Recovery and Flow Control with a Slow Acknowledgement Channel:A study of TCP/IP Performance.

In https://www.wendangku.net/doc/123712203.html,com97(April1997).

[20]M AHDAVI,J.,AND F LOYD,S.The TCP-Friendly Website.

https://www.wendangku.net/doc/123712203.html,/networking/tcp friendly.html,1998. [21]M ATHIS,M.,AND M AHDAVI,J.Forward Acknowledge-

ment:Re?ning TCP Congestion Control.In Proc.ACM SIG-COMM(Aug1996).

[22]M ATHIS,M.,M AHDAVI,J.,F LOYD,S.,AND R OMANOW,

A.TCP Selective Acknowledgment Options.Internet Engi-

neering Task Force,1996.RFC2018.

[23]M C C ANNE,S.,J ACOBSON,V.,AND V ETTERLI,M.

Receiver-driven Layered Multicast.In Proc ACM SIGCOMM (Aug.1996).

[24]ns-2Network Simulator.https://www.wendangku.net/doc/123712203.html,/-

ns/,1998.

[25]O TT,T.,K EMPERMAN,J.,AND M ATHIS,M.The Sta-

tionary Distribution of Ideal TCP Congestion Avoidance.

ftp://https://www.wendangku.net/doc/123712203.html,/pub/tjo/TCPwindow.ps,1996.

[26]P ADHYE,J.,F IROIU,V.,T OWSLEY,D.,AND K UROSE,J.

Modeling TCP throughput:A Simple Model and its Empiri-cal Validation.In Proc.ACM SIGCOMM(Sept.1998).

[27]P ADHYE,J.,K UROSE,J.,T OWSLEY,D.,AND K OODLI,R.

A Model Based TCP-friendly Rate Control Protocol.In Proc.

NOSSDAV(July1999).

[28]P OSTEL,J.B.Transmission Control Protocol.Internet En-

gineering Task Force,September1981.RFC793.[29]R AMESH,S.,AND R HEE,I.Issues in Model-Based Flow

Control.Technical Report TR-99-15,Department of Com-puter Science,North Carolina State University(1999). [30]R EJAIE,R.,H ANDLEY,M.,AND E STRIN,D.Quality Adap-

tation for Unicast audio and video.In Proc.ACM SIGCOMM (September1999).

[31]R EJAIE,R.,H ANDLEY,M.,AND E STRIN,D.RAP:An

End-to-end Rate-based Congestion Control Mechanism for Realtime Streams in the Internet.In Proc.IEEE INFOCOM (March1999).

[32]S CHULZRINNE,H.,C ASNER,S.,F REDERICK,R.,AND J A-

COBSON,V.RTP:A Transport Protocol for Real-Time Ap-plications.Internet Engineering Task Force,Jan1996.RFC 1889.

[33]S ISALEM,D.,AND S CHULZRINNE,H.The Loss-Delay Ad-

justment Algorithm:A TCP-friendly Adaptation Scheme.In Proc.NOSSDAV(Jul1998).

[34]S TEVENS,W.R.TCP/IP Illustrated,Volume1.Addison-

Wesley,Reading,MA,Nov1994.

[35]T AN,W.,AND Z AKHOR,A.Real-time Internet Video Us-

ing Error Resilient Scalable Compression and TCP-friendly Transport Protocol.IEEE Trans.on Multimedia(May1999).

[36]W ANG,A.,AND S CHWARTZ,M.Achieving bounded fair-

ness for multicast and TCP traf?c in the Internet.In Proc.

ACM SIGCOMM(September1998).

[37]W ANG,Z.,AND C ROWCROFT,J.A New Congestion Con-

trol Scheme:Slow Start and Search(Tri-S).ACM Computer Comm.Review21,1(Jan.1991),32–43.