A Hybrid Systems Framework for TCP Congestion Control:A Theoretical Model and its Simulation-based Validation

Stephan Bohacek Jo˜ao P. Hespanha Junsoo Lee Katia Obraczka

bohacek@math.usc.edu hespanha@usc.edu junsoole@usc.edu katia@cse.ucsc.edu

Abstract— In this paper we make use ofhybrid systemsto model the transient and steady-state behavior of multi-ple TCP flows that share a single common bottleneck link.The contributions of our models include: (1) a more com-plete description of TCP’s behavior, including the effect ofqueuing, interaction among competing flows, and finite ad-vertised window size, (2) theoretical prediction of phenom-ena such as flow synchronization which have only been ob-served experimentally; our models predict that, under cer-tain conditions, the window sizes and sending rates of allcompeting flows will synchronize exponentially fast at a rateof ���, where � is the number of drops experienced by aflow, (3) theoretical prediction of other TCP congestion con-trol pathologies, such as unfairness, which previous modelsbased on single-flow analysis fail to capture. In this paper wealso propose mechanisms that mitigate both synchronizationand unfairness.

We validate our approach by constructing a hybridmodel of TCP-Reno and re-deriving well-known relation-ships among congestion control parameters—such as theformula � �� ����

�����, which relates the average through-

put � , the average round-trip time ��� , and the averagepacket drop rate �. We also present simulation results thatvalidate our theoretical predictions.

To our knowledge, this is the first time hybrid systemsare used to model congestion control. We fully characterizeTCP’s behavior in the dumbbell topology, employing pow-erful theoretical tools available for hybrid systems. Whencompared with previous work, we provide a more completecharacterization of TCP, demonstrating the potential of hy-brid systems as a modeling tool for congestion control.

I. I NTRODUCTION

For the past decade, TCP congestion control mecha-nisms have been under the scrutiny of the network researchcommunity. The existence of several versions of TCP suchas TCP-Tahoe, Reno, Vegas, New Reno, and Selective Ac-knowledgement (SACK) is evidence of the attention TCPhas received over the years. More recently, motivated bythe increased popularity of multimedia services, several ef-forts have been investigatingTCP-friendly approaches tocongestion control [1], [2], [3]. One goal of TCP-friendlycongestion control is to avoid the large window size vari-ations that may be experienced by TCP flows and, at the

same time, be able to coexist with TCP in a mutually fairway.

Our work on TCP congestion control was originally mo-tivated by trying to make TCP more robust to intrusion at-tacks. To that effect, we set forth at trying to derive ananalytical model of TCP to help us determine TCP’s base-line behavior and consequently, identify potential attacks.

Yet another model of TCP?

We approach the TCP congestion control problem froma control-theoretic point-of-view. More specifically, weuse a hybrid systems framework which allows us to theo-retically derive specific properties of TCP without the needto make oversimplifying, often unrealistic, assumptions.Hybrid systems [4], which to the best of our knowledgehave not yet been employed to investigate TCP, are formalmodels that combine both continuous time dynamics anddiscrete-time logic. These models permit complexity re-duction through the continuous approximation of variableslike queue and congestion window sizes, without compro-mising the expressiveness of logic-based models. For thespecific case of modeling TCP congestion control, whenno drops occur, all variables are treated as continuouslyvarying variables. When a drop occurs, logic-based mod-els dictate the discrete transitions of the state variables.Hybrid system modeling permits us to derive well-knownresults (which, to some extent, validate our model), as wellas new characterizations of TCP traffic.

In this paper we provide a detailed understanding ofTCP congestion control algorithms through the use of hy-brid models. Similarly to existing models of TCP con-gestion control, we develop our model for thedumbbelltopology1. However, our models provide new insight intothe behavior of TCP congestion control. Unlike the single-flow analysis conducted by other TCP modeling efforts,our model considers multiple TCP flows, which allows us�Several existing models of TCP congestion control have been devel-

oped for the dumbbell topology [5], [6], [7], [8], [2], [9]. In a dumbbelltopology, TCP flows generated at source node�� and directed towardssink node�� compete for t finite bandwidth� that characterizes thebottleneck link� connecting�� to ��. Figure 2 shows the dumbbelltopology we use in our simulations.

to theoretically describe several phenomena that had onlybeen observed experimentally. For example, in the case ofa drop-tail queue, we prove that, under certain conditions,the window sizes and sending rates will synchronize ex-ponentially fast at a rate of��� where� is the number ofdrops experienced by a flow (Theorem 1). To the best ofour knowledge, this is the first formal proof that an opti-mal and fair state of TCP is exponentially stable. Whilesynchronization of TCP flows has long been observed em-pirically [10], [5]—in the form of in-phase periodic varia-tions of the sending rates of competing flows—, a formalproof had not been provided. Neither had the conditionsfor flow synchronization. An apparently neglected condi-tion for the stability of synchronization is that there mustbe a significant mismatch between the bandwidths of thelinks leading to the bottleneck link and the bandwidth ofthe bottleneck link. If this “bandwidth mismatch assump-tion” is not met, the flows will not synchronize. Also, forsynchronization to occur the advertised windows must belarge (sufficiently large to have no effect on the congestionwindow). However, as discussed in Section V, if the adver-tised window assumption does not hold, then pathologicalsituations can occur, e.g., one TCP flow ending up utiliz-ing far more bandwidth than the competing flows. Indeed,it is possible that a sophisticated algorithm could fully ad-here to the principles of TCP and yet acquire an unfairlylarge amount of bandwidth by manipulating its advertisedwindow size.

Many of the recently proposed TCP-friendly algorithmsare based on the well known relationship

� �����

�����

(1)

where � is the average throughput,��� the averageround-trip time, and� the average drop rate [11], [12],[7], [13] or variations of (1) that consider timeouts [14],[2]). Our hybrid systems model provides an alternativederivation of this relationship. One key difference is thatour derivation did not need to make various simplifyingassumptions found in previous work. For example, we donot assume that the round-trip time is constant. As it iswell known, the round-trip time plays an important rolein TCP: when the queue fills, the round-trip time increasesand the TCP congestion window increases more slowly. Inessence, the round-trip time has a stabilizing effect on theTCP flows, evenbefore a drop has occurred. Interestinglyenough, we observe that the relationship between through-put, drop rate, and round-trip time given by Equation (1) isessentially unchanged when the variation of the round-triptime is included.

Our hybrid systems model also allows for the derivation

of many other properties of competing TCP flows. For ex-ample, various relationships between the number of flows,the drop probability, the round-trip time, and the time be-tween drops are derived (Theorem 2). With this level ofdetail about TCP’s behavior, a source can, for example,anticipate congestion and temporarily increase the level oferror correction. For intrusion detection purposes, our de-tailed models of TCP’s congestion control algorithms al-low an accurate characterization of TCP’s baseline behav-ior and thus makes it easier to identify potential attacks.

The remainder of this paper is organized as follows. Thenext section details the hybrid systems framework and de-fines a simplifying normalization of the temporal variable.In Section III, the hybrid systems methodology is used toanalyze TCP-Reno under a drop-tail queuing discipline.This section contains the main theoretical results: expo-nential stability and steady-state characterizations. Sec-tion IV focuses on the issue of flow synchronization. Asnoted above, in the case of a small advertised window,synchronization can lead to drastic unfairness. The exactmechanisms for this unfairness is detailed in Section V. Fi-nally, Section VI provides a summary of the results, someconcluding remarks, and our future work plans.

II. H YBRID SYSTEM MODELING FORCONGESTION

CONTROL

We start by describing how TCP’s congestion controlmechanism can be modeled using a hybrid system, i.e., asystem that combines continuous dynamics with discretelogic. We consider here a simplified version of TCP-Renocongestion control [15], [16], [17] but the model proposedalso applies to more recent variations on Reno such asNew Reno, SACK [6], and general AIMD [18]. We de-note by��� the round-trip time, and by�� and ���

� ,� � ��� �� � � � � � the window size and slow-start thresh-old, respectively, for the congestion controller associatedwith the �th flow. As we will see shortly, the round-triptime is a time-varying quantity.

In Reno, the algorithm to update�� is as follows: Whilethe window size�� is below the slow-start threshold���

� ,the congestion controller is in theslow-start mode and��is multiplied by a fixed constant�� (typically �� � �)every round-trip-time��� . When the window size raisesabove���

� , the controller enters thecongestion avoidancemode and�� is incremented by a fixed constant� � �every round-trip-time��� . The above takes place un-til a drop occurs. A drop can be detected through twomechanisms that lead to different reactions by the con-gestion controller. When the drop is detected becauseof the arrival of three consecutive duplicate acknowledg-ments,�� is multiplied by a constant � ��� �� (typi-

cally � ���) and the system proceeds to the congestionavoidance mode. In some cases, three consecutive dupli-cate acknowledgments never arrive and a drop is detectedwhen a packet remains unacknowledged for a period oftime longer than theretransmission timeout �� . In thiscase, the slow-start threshold is set equal to�� and�� isreduced to one. Unless there are many consecutive dropsper flow, timeouts occur mostly when the window size be-comes smaller than four and therefore no three duplicateacknowledgments can arrive after a drop.

Although the window size takes discrete values, it isconvenient to regard it as a continuously varying variable.The following hybrid model provides a good approxima-tion of the�th window size dynamics: While the�th flowsuffers no drops, we have in the slow start mode2

��� � ������������ (2)

and in the congestion avoidance mode

��� � ������ (3)

When a drop is detected at time� through three duplicateacknowledgements, we have

����� � ��� ����

where��� ��� denotes the limit from below of����� as� ��, and when the drop is detected through timeout, we have

���� ��� � ��� ���� ����� � ��

The round-trip time is given by��� ��� � �� � �������where �� denotes thepropagation time (together withsome fixed component of the service time at nodes � and �) and���� is the size of the output queue of node � attime �. We assume here that the bandwidth� is measuredin packets per second. Denoting by����

� the advertisedwindow size for the�th flow, the output queue at node �receives a total of

� �� ���

�� ���� ����� ������

packets per second and is able to send� packets to thelink in the same period. The difference between these twoquantities determines the evolution of����. In particular,

�� �

�� � � �� � � � or � � ��� � � �

� �� otherwise(4)

�This equation leads precisely to a multiplication by��� on eachround-trip time��� .

The first branch in (4) takes into account that the queuesize cannot become negative nor should it exceed themax-imum queue size ��. When���� reaches�� drops oc-cur. These will be detected by the congestion controllerssome time later.

As mentioned above, drops will occur whenever�reaches the maximum queue size��, and the rate of in-coming packets to the queue� exceeds the rate� of out-going packets. Typically, drops detected through duplicateacknowledgments will be detected roughly one round-triptime after they occur, whereas the one detected throughtimeout will be detected�� seconds later. Because ofthis delay in detecting a drop, the rate of incoming pack-ets will not change immediately after the queue becomesfull and multiple drops are expected. To complete ourmodel we need to know which flows will suffer a dropduring this interval. To determine exactly the set of flows� ��� �� � � � � � that suffer a drop, one would need tokeep track of which packets are in the queue, leading toa complex packet-level model. However, for purposes oftraffic flow analysis, it is sufficient to assume that� is afunction of the window sizes of the individual flows (��).Denoting by���� the set of flows that suffer drops at time�, we have

���� � ����

���� ��� � � � � ��

�� (5)

We call���� thedrop model. As we shall see below, sev-eral drop models are possible, depending on the queuingdiscipline.

Although drops are essentially discrete phenomena, wecan incorporate them in our hybrid model by consid-ering distinct modes (or discrete states) for the system.Four modes should be considered to cover all possiblecases: slow-start or congestion avoidance and, in eachcase, queue full or not. The queue-full modes are activefrom the moment� reaches�� until the drops are de-tected and congestion control reacts leading to a decreasein the queue size�. The time it takes for this to happen iseither�� or��� depending on whether�� was smallerthan 4 or not at the time of the drop. When the drop is de-tected, the flows in� will suffer the appropriate changes intheir window sizes and slow-start thresholds. The transi-tion from slow-start to congestion avoidance occurs whenthe window size�� exceeds the slow-start threshold���

� .The system is initialized with all�� equal to one and���� equal to infinity. Figure 1 contains a graphical rep-

resentation of the resulting hybrid system. Each ellipsein this figure corresponds to a discrete mode and the con-tinuous state of the hybrid system consists of the queuesize�, the window sizes and slow-start thresholds��� �

��� ,

� � ��� �� � �, and a timing variable��� used to en-force that the system remains in thequeue-fullmodes foreither�� or ��� seconds. The differential equationsfor these variables in each discrete mode are shown in-side the corresponding ellipse. For simplicity we assumehere that the queue size� never reaches zero. The arrowsin the figure represent discrete transitions between modes.These transitions are labeled with their enabling conditions(followed by “?”) and any necessary reset of the continu-ous state that must take place when the transition occurs(with the corresponding assignments denoted by��). Weassume here that a jump always occurs when the transi-tion condition is enabled. The transition on the top-leftentering theslow-start/queue-not-full represents the sys-tem’s initialization. This model is consistent with most ofthe hybrid system frameworks proposed in the literature(cf. [4] and references therein).

Although we focused our presentation on Reno conges-tion control, it is also possible to construct hybrid modelsfor other congestion control algorithms [19].

The following are the key novel features of the hybridmodels presented above:1. They consider a continuous approximation for thequeue dynamics and the window sizes. This avoids thecomplexity inherent to a detailed packet-level descriptionthat results from coupling congestion control with the errorcorrection protocol.2. They model packet drops as events that trigger transi-tions between discrete modes with distinct continuous dy-namics. The flexibility of combining continuous dynamicswith discrete logic can be exploited to model existing andnovel congestion control mechanisms and queuing poli-cies.3. Although we utilized a deterministic hybrid system inthe example above, one can incorporate in this type ofmodel stochastic events that trigger transitions. This isneeded to model random queuing disciplines such as Ran-dom Early Detection/Drop active queuing [20].

III. A NALYSIS OF TCP-RENO WITH DROP-TAIL

QUEUING

In this section we study the dynamics of the TCP-Renocongestion control model in Figure 1 under drop-tail queu-ing and infinitely large advertised window size. We as-sume here that the window sizes do not decrease below 4and therefore the system only stays in slow-start for a briefinitial period.

To complete the hybrid model it remains to specify thedrop dynamics that determine the set of flows� that sufferdrops while the system is in one of thequeue-fullmodes.

It turns out that under drop-tail queuing policy exactly onedrop per flow will occur in most operating conditions [5].To understand why, we must recall that, while there are nodrops, in every round-trip time the window size of eachflow will increase because each flow will receive as manyacknowledgments as its window size. When the acknowl-edgment that triggers the increase of the window size by� � � arrives, the congestion controller will attempt tosend two packetsback-to-back. The first packet is sent be-cause the acknowledgment that just arrived decreased thenumber of unacknowledged packets and therefore a newpacket can be sent. The second packet is sent because thewindow size just increased, allowing the controller to havean extra unacknowledged packet. However, at this pointthere is a very fragile balance between the number of pack-ets that are getting in and out of the queue, so two packetswill not fit in the queue and the second packet is dropped.Formally, this corresponds to the followingone-drop-per-flow model

� � ����

���� ��� � � � � ��

��� ��� �� � � � � �� (6)

For a very large number of flows, a single drop per flowmay not be sufficient to produce the decrease in the win-dow size required to make the queue size drop below��

after the multiplicative decrease. In this case, the one-drop-per-flow model is not valid. However, we shall seein Section III-B that, for most operating conditions, thismodel accurately matches packet-level simulations per-formed using thens-2 network simulator [21]. In fact,this hybrid model only fails when the number of flows isso large that the drop rates take very large values.

A. Transient Behavior

We proceed now to analyze the joint evolution of thewindow sizes of all the flows. Our analysis shows thatthe window sizes converge to a periodic regimen, regard-less of their values at the end of the slow-start period. Be-cause we are considering the variations of the round-trip-times caused by varying queuing delays, this regimen ismore complex (but also closer to reality) than the simplesaw-tooth wave form that is often used to characterize thesteady-state behavior of this type of algorithms. We are in-terested here in characterizing the short-term evolution—also known as thetransient behavior—of the window sizesuntil the periodic regimen is reached. The following isproved in [19] (the proof was omitted here for lack ofspace.)

Theorem 1: Let ��� � �� � ����� � � �� be theset of times at which the system enters thecongetionavoidance/queue-not-fullmode. For infinitely large adver-tised window size����

� and�� ���� � ������, all the

cong. avoid./queue-not-full:

�� � � ��� � ���

cong. avoid./queue-full:

�� � �� ����� � ���� � ���

cong. avoid./timeout:

�� � �� ����� � ���� � ���

slow-start/queue-not-full:

�� � � �

�� �������

� �

slow-start/queue-full:

�� � �� ����� � ���� �

������

� �

slow-start/timeout:

�� � �� ����� � ���� �

������

� �

� � ����,� � ,� � �?

���� ��� � ���� � �?

� �� �,

�� ��

��

�

�

� � �

� � ����,� � ,� � �?

���� ���

���� � �?

� �������� �� � �

� � ����,� � ,� � �?

���� ���

� �������� �� � �

� � ����,� � ,� � �?

���� ��� �

���� � �?

� �� �,�� ��� � � �

�

���� � �?

� �� �,

�� ��

��

�

�

� � �

Fig. 1. Hybrid model for TCP-Reno.

������, � � ��� �� � � � � � converge exponentially fast to

�� ���

���������� � ��� (7)

as� � and the convergence is as fast as�. In (7),��is the unique solution to

�� � ��� � �������

��

��

���� �������

where� � ��� �� ��� � denotes the smooth bijection

� ���

������ � � � �� �

� � � ��

The condition�� ���� � ������ essentially limits the

maximum number of flows under which the one-drop-per-flow model is valid. When this condition is violated, i.e.,when

���

����� ������

a single drop per flow may not be sufficient to produce adecrease in the sending rates that would make� drop below�� after the multiplicative decrease.

We defer to Sections IV and V a detailed discussion ofthe implications of Theorem 1 and proceed with the anal-ysis of the model.

B. Steady-state behavior

In the previous section we established that the windowsizes converge to a periodic regimen, also known as the

steady-state regimen. We proceed now to analyze the sys-tem when it operates under this regimen. Among otherthings, we will show that the relationship between aver-age throughput, average drop rate (i.e., the percentage ofdropped packets), and average round-trip time that appearsin [11], [12], [7], [13] can also be derived from our model.In this section we concentrate on the case where�� ismuch larger than one and therefore

������� � �� � �� (8)

This approximation is valid when

� ��

����� ����� (9)

and causes the system to remain in the statecongestion-avoidance/queue-not-fullfor, at least, a few round-triptimes3. In practice, this is quite common and a deviationfrom (9) results in very large drop rates.

Suppose then that the steady-state has been reachedand let us consider an interval���� ����� between twoconsecutive time instants at which the system enters thecongestion-avoidance/queue-not-fullstate. Somewhere inthis interval lies the time instant��� at which the system en-ters thecongestion-avoidance/queue-fullstate and dropsoccur. During the interval���� �����, the instantaneous rate� at which the nodes are successfully transmitting packets

When the system remains in thequeue-not-fullfor at least 4 round-trip times, (8) already yields an error smaller than 2%.

is given by

���� �

������ ����� ��� � � ���� ����

� � � ����� �����(10)

The total number of packets�� sent during the interval���� ����� can then be computed by

�� ��

� ����

��

������ � ���

����� ���� � �����

(11)

Details on the computation of the integrals in (11) and in(13) below are given in [19]. Since drops occur in theinterval ���� �����, the average drop rate � is then equal to

� ��

��� ��

���

�

�� ���� � ��

��

� (12)

Another quantity of interest is the average round-trip time��� . We consider here a packet-average, rather than atime-average, because the former is the one usually mea-sured in real networks. This distinction is important sincethe sending rate� is not constant. In fact, when the send-ing rate is higher, the queue is more likely to be full and theround-trip time is larger. This results in the packet-averagebeing larger than the time-average. Thepacket-averageround-trip time can then be computed as

��� ��

� ������

������� �����

��

� �

�

��

�

���

���

�� ���� � ��

� �

��

� �

��

(13)

where� �� � is the average throughput of each flow.

We recall that, because the queue never empties, the totalthroughput is precisely the bandwidth� of the bottlenecklink.

It is interesting to note that the average drop rate� canprovide an estimate for the quantity �

����� ����� . In par-ticular, we conclude from (12) that

�� ���� � ��

�

��

������� (14)

This, in turn, can be used together with (13) to estimatethe average throughput� . In fact, from (13) and (14) weconclude that

� � �

���

�

�

���

���

��

������� �

��

� �

�

The following theorem summarizes the results above forthe hybrid model for TCP-Reno congestion control in Fig-ure 1:

Theorem 2: For infinitely large advertised window size����� and�� � ��� � ���

���, the average drop rate�,

the packet average round-trip time��� , and the averagethroughput� of each flow are approximately given by

� � ��

���

�

�� ���� � ��

��

� (15)

��� �

�

��

�

���

���

�� ���� � ��

� �

��

� �

��

(16)

� � �

���

�

�

���

���

��

������� �

��

� �

��

(17)To verify the formulas in Theorem 2, we simulated the

dumbbell topology of Figure 2, using thens-2 networksimulator [21]. Figure 3 summarizes the results obtained

10Mbps/20ms

TCP Sinks

N2

Router R1

Router R2

Bottleneck Link

Incomming

LinksFlow 1

Flow 2

N1

Nn-1

Nn

TCP Sources

S1

S2

Sn-1

Sn

Flow N-1

Flow N

Fig. 2. Dumbbell topology with n TCP flows, 10 Mbps bottle-neck link, 100 Mbps incoming links, 40 millisecond roundtrip propagation delay, and queue size at the bottleneck linkof 250 packets.

for a network with the following parameters:

� ���� bits/sec

� bits/char� ���� char/packet� ���� packets/sec�

�� � ��� sec,�� � ��� packets,� � � packet/RTT, � ���. As seen in the figure, the theoretical predictionsgiven by (15)–(17) match the simulation results quite accu-rately. Some mismatch can be observed for large numberof flows. However, this mismatch only starts to becomesignificant when the drop rates are around 1%, which isan unusually large value. This mismatch is mainly dueto two factors: the quantization of the window size and a

100

101

10−5

10−4

10−3

10−2

n

Drop rate

NS simulation Theoretical prediction

100

101

0

0.05

0.1

0.15

0.2

0.25

0.3

n

Average round−trip time

NS simulation Theoretical prediction

100

101

102

103

n

Throughput

NS simulation Theoretical prediction

Fig. 3. Comparison between the predictions obtained from the hybrid model and the results fromns-2 simulations.

crude modeling of the fast-recovery algorithm [16]. Weare now in the process of incorporating these two featuresinto our model to obtain formulas that are accurate also invery congested networks.

C. Comparison with Previous Results

For� � � and � ���, the formula (17) becomes

� � �

���

�������� �

�

�� (18)

For reasonable drop rates, the term����� dominates over

1/3 and (18) matches closely similar formulas derived in[11], [12], [7], [13]. However, the analysis presented heregoes several steps further than the ones presented in thesereferences because of the following: (i) previous deriva-tions of (17) ignored queuing, assumed constant round-trip time, considered a single flow, and ignored transientbehavior; (ii) the results in Theorem 1 provide informa-tion about the transient behavior of the individual flows;(iii) Theorem 2 also provides a more complete descriptionof the steady-state behavior of TCP because it gives ex-plicit formulas for the average round-trip time��� andthe drop rate� as a function of the number of flows. Itis important to emphasize that��� in (16) denotes theaverage round-trip time. It turns out that the actual round-trip-time��� varies quite significantly around this aver-age because of fluctuations on the queue size. In fact, evenafter the steady-state is reached, the variation of the “in-stantaneous” round-trip time is often larger then 50% ofthe average round-trip time.

IV. FLOW SYNCHRONIZATION

One conclusion that can be drawn from Theorem 1 isthat all flows converge exponentially fast to the same limitcycle. This limit cycle corresponds to a continuous in-crease of the window size from�� to �

���, followed byan instantaneous decrease back to�� due to drops. Be-

cause all flows converge to thesame limit cycle, this meansthat the flows will become synchronized. We were able toobserve this synchronization effect inns-2 simulationsusing the dumbbell topology. Figure 4 plots the conges-tion window of 8 TCP-Reno flows and the queue size atthe bottleneck link. Even though each flow starts at a ran-dom time between 0 and 5 seconds, we observe that theyare almost perfectly synchronized at around 30 seconds.

0

100

200

300

400

500

600

0 10 20 30 40 50

Cw

nd a

nd Q

ueue

Siz

e(P

acke

ts)

Time (seconds)

12345678

Queue Size

Fig. 4. Congestion window and bottleneck link queue size forthe default dumbbell topology with� � � flows.

Window size synchronization had been observed in[10], [5] for TCP-Tahoe congestion control [6] and ac-tually led to the development of Random Early Detec-tion/Drop active queuing [22], [20]. In [5], the authorsdefend that synchronization is closely related to the packetloss synchronization that we also use in our model. Infact, they provide an informal explanation—supportedby packet-level simulations—of how synchronization isa self-sustained phenomenon. Although [5] only dealswith TCP-Tahoe congestion control, the arguments usedthere also apply to Reno. Theorem 1 goes much furtherbecause it demonstrates that synchronization is not justself-sustained but it is actually an exponentially attractingstate. This means that synchronization will occur even ifthe flows start unsynchronized or lose synchronization be-

cause of some temporary disturbance. Moreover, the con-vergence to this state is very fast and the distance to it isreduced by at least (typically 1/2) with each drop. Tothe best of our knowledge this is the first time that thesetype of theoretical results were obtained. Note that syn-chronization cannot be captured by single-flow models.

As long as the output queue of node � does not getempty (which was the case in all our simulations), the bot-tleneck link is used at full capacity and flow synchroniza-tion does not have any effect on the average throughput.However, it does produce large variations on the size ofthe bottleneck queue and therefore large variations on theround-trip time. The network traffic also becomes morebursty and network resources are used unevenly. Thelarger variations on the round-trip time are particularlyharmful to TCP because they often lead to inefficient time-out detection. They are also a problem for multimediaflows that cannot withstand large delay jitter, i.e., delayvariation associated with the delivery of packets belongingto a particular flow.

Three assumptions were instrumental in the proof ofTheorem 1: infinite (or very large) advertised window size,drop-tail queuing, and large bandwidth mismatch betweenthe data sources and the bottleneck link. The last assump-tion is actually implicit in the dumbbell topology in Fig-ure 2. It was under these three assumptions that we derivedthe one-drop-per-flow model (6). Indeed, without a limiton the advertised window size, each flow will increase itswindow size by one while the system is in thecongestion-avoidance/queue-fullmode. When this increase takesplace, the large bandwidth mismatch between incomingand bottleneck links results in back-to-back packets arriv-ing at the bottleneck link queue. Finally, under a drop-tailpolicy the second packet is dropped resulting in exactlyone drop per flow. The next section discusses the impactof finite advertised window sizes. In the remaining of thissection, we study the link bandwidth mismatch issue andthe effect of queuing policies other than drop-tail on flowsynchronization.

Even though the source generates back-to-back pack-ets when the window size is increased, these packets donot arrive back-to-back at the bottleneck link, when theincoming link has finite bandwidth. In fact, the smallerthe bandwidth of the incoming link, the more spread willthe packets arrive at the bottleneck link. This can be seenin Figure 5 that shows a trace of packets arriving at thebottleneck link from each of the incoming links. The twoplots in figure 5(a) correspond to the topology in Figure 2with a bandwidth of 20Mbps in the incoming link, versus10Mbps in the bottleneck link. The bottom plot is just a

zoomed version of the top one. Although the packets nolonger arrive exactly back-to-back, we still have one dropper flow and synchronization occurs. In the lower plot inFigure 5(a), we can actually see the effect of a windowsize increase and the corresponding drop in flow 4 at time502.623 seconds. Figure 5(b) contains similar plots butfor an incoming link bandwidth of 15Mbps. We can see inthis plot that a back-to-back packet in flow 8 at time 501.90seconds actually causes a drop in flow 1.

We also investigated what effect different queuing dis-ciplines have on flow synchronization. Figure 6(a) showsthat by using a simpledrop-head queuing policy (drop thepacket at the head of the queue)—while keeping all theother dumbbell characteristics the same—we are able toeliminate synchronization. Figure 6(b) shows that Ran-dom Early Detection (RED) queuing also eliminates flowsynchronization by adding randomization to the network,as suggested in [22].

It is interesting to note that a deterministic queuing dis-cipline such as drop-head can be very effective in break-ing synchronization. This is not completely surprising be-cause there is not a significant difference between the dis-tribution of the packets that are at the head of the queueand any random packet in the queue. Therefore drop-headis not significantly different from random-drop [23], [24].However, when compared to random-drop and RED, drop-head has the advantage that drops will be detected soonersince queuing delay is minimized. Drop-head is thereforethe most responsive of these algorithms. Incorporating dif-ferent queuing disciplines (including random-drop and de-terministic early drop) into our models and developing theformal analysis for them is an item for future work.

V. FAIRNESS

From Theorem 1 we can conclude that all flows con-verge to the same limit cycle and therefore TCP-Reno con-gestion control is asymptotically fair. Although this hasgenerally been accepted as true, a formal proof of thisproperty of TCP for an arbitrary number of flows, takingqueuing into account, had not been developed before. In-deed, this is one of the contributions of this work.

It turns out that fairness may be lost when the assump-tions used to derive Theorem 1 do not hold. In particular,when some or all the flows have finite advertised windowsizes. The graph in Figure 7(a) demonstrates this behav-ior. It plots the congestion window size of 8 TCP-Renoflows all of which are limited by an advertised windowsize of 50 packets. We observe that 4 out of the 8 flows areable to reach the maximum window size of 50 packets andkeep sending at that constant rate throughout the simula-

12345678

502.6 502.65 502.7 502.75 502.8

Flo

ws

Time (seconds)

arrivaldrop

12345678

501.8 501.85 501.9 501.95 502

Flo

ws

Time (seconds)

arrivaldrop

12345678

502.6 502.65

Flo

ws

Time (seconds)

arrivaldrop

12345678

501.89 501.92 501.95

Flo

ws

Time (seconds)

arrivaldrop

(a) (b)

Fig. 5. Packet traces for (a) 20 Mbps and (b) 15 Mbps incoming link bandwidths.

0

50

100

150

200

250

1500 1510 1520 1530 1540 1550

Cw

nd a

nd Q

ueue

Siz

e(P

acke

ts)

Time (seconds)

12345678

Queue Size

0

20

40

60

80

100

120

1500 1510 1520 1530 1540 1550

Cw

nd a

nd Q

ueue

Siz

e(P

acke

ts)

Time (seconds)

12345678

Queue Size

(a) (b)

Fig. 6. Congestion window and bottleneck link queue size for the default dumbbell topology using (a) drop-head queuing and (b)RED queuing.

tion. Because they will not further increase their sendingrates, these flows will never attempt to send back-to-backpackets, making it very unlikely that they will suffer drops.The remaining flows were not able to reach the advertisedwindow size (possibly because they started slightly later)and therefore they will surely suffer drops when the bottle-neck queue fills up. In this specific scenario, TCP favorsthe first four flows to start, which end up exhibiting almostfour times higher throughput than the remaining flows.

Similar behavior is observed when simulating scenariosin which only a few flows have limited advertised windowsize. Figure 7(b) shows the simulation results when 2 (outof 8) flows are limited by a 50-packet advertised window.It is interesting to observe that one of these flows is the sec-ond flow to start and is able to achieve the 50-packet win-dow size limit. Since it never sends back-to-back packets,it never suffers packet drops and is thus able to keep send-

ing packets at the maximum rate (corresponding to a 50-packet window size). The other flow, which is also limitedby a 50-packet advertised window size, ends up startinglast and behaves like all other flows, suffering drops peri-odically. This is because the bandwidth is not sufficient toallow the last flow to reach the 50-packet window size.

The next set of graphs demonstrate that, by using dif-ferent queuing disciplines, unfairness can be avoided. In-deed, Figure 8 shows that both drop-head and RED queu-ing eliminate unfairness when all flows have finite adver-tised window size. Both queuing policies result in nor-malized average throughputs just a few percentage pointsaway from one. When some flows have finite advertisedwindow size and others do not, we observe that the latterare at an advantage and exhibit larger normalized through-puts. This is expected and occurs both with drop-headqueuing and RED. A simulation for the drop-head case is

0

50

100

150

200

250

0 10 20 30 40 50

Cw

nd a

nd Q

ueue

Siz

e(P

acke

ts)

Time (seconds)

12345678

Queue Size

0

100

200

300

400

500

600

0 10 20 30 40 50

Cw

nd a

nd Q

ueue

Siz

e(P

acke

ts)

Time (seconds)

12345678

Queue Size

(a) (b)

Fig. 7. Congestion window and bottleneck link queue size for the default dumbbell topology when (a) all flows have 50-packetadvertised window size and (b) only flows 1 and 2 have finite (50-packet) advertised window size. In (a) four of the flowsexhibit a normalized throughput of 138% and the remaining a normalized throughput in the range���� ��, in (b) one flowexhibits a normalized throughput of 167% and the remaining a normalized throughput of�� ���

0

50

100

150

200

250

1500 1510 1520 1530 1540 1550

Cw

nd a

nd Q

ueue

Siz

e(P

acke

ts)

Time (seconds)

12345678

Queue Size

0

20

40

60

80

100

120

1500 1510 1520 1530 1540 1550

Cw

nd a

nd Q

ueue

Siz

e(P

acke

ts)

Time (seconds)

12345678

Queue Size

(a) (b)

Fig. 8. Congestion window and bottleneck link queue size for the default dumbbell topology where all flows have 50-packetadvertised window size using (a) drop-head and (b) RED queuing. In (a) all flows exhibit a normalized average throughput inthe range�� ���� and in (b) in the range�� ����.

shown in Figure 9.

One item for future work is the use of formal methods topredict and explain when TCP exhibits an unfair behavior,as well as ways to avoid it. The hybrid models in Figure 1already take into account finite advertised windows sizesbut the drop model (6) in Section III does not. One sim-ple model that can capture the phenomena described abovewith drop-tail queuing is given by

� � ����

���� ��� � � � � ��

��� �� � �� � ����

� �� (19)

because drops will most likely only occur in those flows�that did not yet reach their advertised window sizes����� .Using the drop model (19), one should be able to predictwhen will finite advertised window sizes result in unfair-ness and which values for the throughputs are expected.We are now in the process of deriving drop-models analo-gous to (19) for drop-head queuing and RED. These shouldallow us to demonstrate that these queuing policies solvethe fairness problem and also to quantify precisely how ef-

fective these policies are in achieving this. Note that thistype of analysis is only possible with multiple-flow modelslike the ones considered here.

VI. CONCLUSIONS

In this paper we proposed a hybrid model for TCP con-gestion control. Using this model, we analyzed both thetransient and steady-state behavior of competing TCPflows on a dumbbell network topology. Besides using ourmodel to confirm well-known formulas, we also used it toderive new relationships and thus provide a more completedescription of TCP’s steady-state behavior. Our model en-abled us to explain the flow synchronization phenomenathat have been observed in simulations and in real net-works but, to the best of our knowledge, have not been the-oretically justified. We were also able to demonstrate thatthe limit cycle that corresponds to flow synchronization isglobal exponentially stable. This means that synchroniza-tion will occur even if the flows start unsynchronized or

0

50

100

150

200

250

1500 1510 1520 1530 1540 1550

Cw

nd a

nd Q

ueue

Siz

e(P

acke

ts)

Time (seconds)

12345678

Queue Size

Fig. 9. Congestion window and bottleneck link queue size forthe default dumbbell topology where flows 1 and 2 have50-packet advertised window size using drop-head queuing.The flows with finite advertised window size exhibit a nor-malized average throughput in the range���� ���� andthe remaining flows in the range������ ����.

loose synchronization because of temporary disturbances.

Another contribution of our hybrid model was that it al-lowed us to identify conditions under which TCP fairnessis lost. We observed TCP’s unfair behavior when some orall flows have finite advertised window size.

We also showed methods to avoid synchronization andunfairness. Throughout the paper, experimental results ob-tained throughns-2 simulations were used to support ourtheoretical analysis.

To our knowledge, this was the first time hybrid systemswere used to model congestion control. We fully charac-terized TCP’s behavior in the dumbbell topology, employ-ing powerful theoretical tools available for hybrid systems.When compared with previous work, we provided a morecomplete characterization of TCP, demonstrating the po-tential of hybrid systems as a modeling tool for congestioncontrol algorithms. We are now in the process of gener-alizing the analysis presented here to more complex net-work topologies and traffic loads (e.g., flows with differ-ent propagation delays and different duration), other con-gestion control mechanisms (such as delayed acknowledg-ments, fast recovery), other TCP variations (e.g., TCP-Vegas and Equation-Based), and different queuing poli-cies (such as drop-head, random-drop, RED, and SRED).We are also investigating alternative mechanisms to avoidsynchronization and unfairness. Another direction we areexploring is the application of the hybrid models derivedhere to detect abnormalities in TCP traffic flows. This hasimportant applications in network security.

REFERENCES

[1] Jitendra Padhye, Jim Kurose, Don Towsley, and Rajeev Koodli,“A TCP-friendly rate adjustment protocol for continuous media

flows over best effort networks,” Tech. Rep. TR 89-04, UMASS-CMPSCI, 1998.

[2] Sally Floyd, Mark Handley, Jitendra Padhye, and J¨org Widmer,“Equation-based congestion control for unicast applications,” inProc. of SIGCOMM, Stockholm, Sweden, Aug. 2000, pp. 43–56.

[3] D. Bansal and H. Balakrishnan, “Binomial congestion controlalgorithms,” Proc. of INFOCOMM, Apr. 2001.

[4] Arjan van der Schaft,An Introduction to Hybrid Dynamical Sys-tems, Number 251 in Lecture Notes in Control and InformationSciences. Springer-Verlag, London, 2000.

[5] Lixia Zhang, Scott Shenker, and David D. Clark, “Observationson the dynamics of a congestion control algorithm: The effects oftwo-way traffic,” inProc. of SIGCOMM, Sept. 1991.

[6] K. Fall and S. Floyd, “Simulation-based comparisons of TahoeReno and SACK TCP,”Computer Comm. Review, vol. 27, no. 3,pp. 5–21, July 1996.

[7] Matthew Mathis, Jeffrey Semke, Jamshid Mahdavi, and TeunisOtt, “The macroscopic behavior of the TCP congestion avoidancealgorithm,” Computer Comm. Review, vol. 27, no. 3, July 1997.

[8] Robert Morris, Scalable TCP Congestion Control, Ph.D. thesis,Harvard University, Cambridge, MA, Jan. 1999.

[9] Eitan Altman, Chadi Barakat, and Emmanuel Laborde, “Fairnessanalysis of TCP/TP,” inProc. of the 39th Conf. on Decision andContr., Dec. 2000, pp. 61–66.

[10] E. Hashem, “Analysis of random drop for gateway congestioncontrol,” Tech. Rep., MIT, 1990.

[11] Jamshid Mahdavi and Sally Floyd, “TCP-friendly unicast rate-based flow control,” Technical note sent to the end2end-interestmailing list, Jan. 1997.

[12] T. V. Lakshman, U. Madhow, and B. Suter, “Window-based errorrecovery and flow control with a slow acknowledgment channel:A study of TCP/IP performance,” inProc. of INFOCOMM, Apr.1997.

[13] V. Misra, W. Gong, and D. Towsley, “Stochastic differential equa-tion modeling and analysis of TCP-windowsize behavior,” inInProceedings of PERFORMANCE99, Istanbul, Turkey, 1999.

[14] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, “Modeling TCPthroughput: a simple model and its empirical validation,” inProc. of SIGCOMM, Sept. 1998.

[15] Van Jacobson, “Congestion avoidance and control,” inProc. ofSIGCOMM, Aug. 1988, vol. 18.4, pp. 314–329.

[16] Van Jacobson, “Modified TCP congestion avoidance algorithm,”Posted on end2end-interest mailing list, Apr. 1990, Available atftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt.

[17] M. Allman, V. Paxson, and W. Stevens, “TCP congestion con-trol,” RFC 2581, p. 13, Apr. 1999.

[18] Y. Yang and S. Lam, “General AIMD congestion control,” inProc. of ICNP, Osaka, Japan, Nov. 2000.

[19] Stephan Bohacek, Jo˜ao Pedro Hespanha, Junsoo Lee, and Ka-tia Obraczka, “A hybrid systems framework for TCP congestioncontrol: A theoretical model and its simulation-based validation,”Submitted to the 39th Annual Allerton Conference on Communi-cation, Control, and Computing., July 2001.

[20] Sally Floyd and V. Jacobson, “Random early detection gatewaysfor congestion avoidance,”IEEE/ACM Trans. on Networking, vol.1, no. 4, pp. 397–413, Aug. 1993.

[21] The VINT Project, a collaboratoin between researchers at UCBerkeley, LBL, USC/ISI, and Xerox PARC,The ns Manual (for-merly ns Notes and Documentation), Oct. 2000, Available athttp://www.isi.edu/nsnam/ns/ns-documentation.html.

[22] Sally Floyd and V. Jacobson, “On traffic phase effects in packet-switched gateways,”Internetworking: Research and Experience,vol. 3, no. 3, pp. 115–116, Sept. 1992.

[23] Van Jacobson, “Minutes of the performance working group,”Proc. of the Cocoa Beach Internet Engineering Task Force, Re-ston, VA, Apr. 1989.

[24] Allison Mankin, “Random drop congestion control,” inProc. ofthe ACM Symposium on Communications Architectures and Pro-tocols, Sept. 1990, pp. 1–7.