A Model Based TCP-Friendly Rate Control
`Protocol
`
`Jitendra Padhyey,
`
`Jim Kurosey,
`
`Don Towsleyy,
`
`Rajeev Koodliz
`
`yDept. of Computer Science,
`University of Massachusetts
`Amherst, MA
`fjitu,kurose,towsleyg@cs.umass.edu
`
`zNokia Research Center,
` , Burlington Woods Drive,
`Burlington, MA 
`rajeev.koodli@research.nokia.com
`
`Abstract| As networked multimedia applications
`become widespread,
`it becomes increasingly im-
`portant to ensure that these applications can co-
`exist with current TCP-based applications. The
`TCP protocol is designed to reduce its sending rate
`when congestion is detected. Networked multime-
`dia applications should exhibit similar behavior, if
`they wish to co-exist with TCP-based applications
` . Using TCP for multimedia applications is not
`practical, since the protocol combines error con-
`trol and congestion control, an appropriate com-
`bination for non-real time reliable data transfer,
`but inappropriate for loss-tolerant real time appli-
`cations. In this paper we present a protocol that
`operates by measuring loss rates and round trip
`times and then uses them to set the transmission
`rate to that which TCP would achieve under similar
`conditions. The analysis in   is used to determine
`this TCP-friendly" rate. This protocol represents
`a rst step towards developing a comprehensive pro-
`tocol for congestion control for time-sensitive mul-
`timedia data streams. We evaluate the protocol
`under various trac conditions, using simulations
`and implementation. The simulations are used to
`study the behavior of the protocol under controlled
`conditions. The implementation and experimenta-
`tion involve over experiments over the Inter-
`net, using several machines in the US and UK. Our
`experimental and simulation results show that the
`protocol is fair to TCP and to other sessions run-
`ning TFRCP, and that the formula-based approach
`to achieving TCP-friendliness is indeed practical.
`
`I. Introduction
`
`Networked multimedia applications usually employ
`non-TCP protocols usually UDP with some applica-
`tion level control to transmit continuous media CM
`
`This material is based upon work supported by the National
`Science Foundation under Grant Nos. CDA-  and NCR-
` . Part of the work was done when the rst author
`worked for Nokia Research.
`
`data such as audio and video. As these applications
`become widespread, it becomes increasingly impor-
`tant to ensure that they are able to co-exist with each
`other and with current TCP-based applications. A
`key requirement of such a co-existence is the imple-
`mentation of some form of congestion control that re-
`sults in a reduction of transmission rate in the face of
`network congestion. Many current CM applications
`simply transmit data at the rate at which it was en-
`coded, regardless of the congestion state of the net-
`work.
`
`Two major considerations come into play when de-
`signing a congestion control protocol for CM appli-
`cations. First, because these applications are both
`loss-tolerant and time-sensitive, the transmission rate
`might best be adapted in a manner that is cognizant
`of the loss resilience and timing constraints of the ap-
`plication  , . Second, since the applications must
`co-exist with TCP-based applications, the congestion
`control algorithms should adapt their rate in a way
`that fairly" shares congested bandwidth with TCP
`applications. One denition of fair" is that of TCP
`friendliness"    if a non-TCP connection shares a
`bottleneck link with TCP connections, traveling over
`the same network path, then the non-TCP connec-
`tion should receive the same share of bandwidth i.e.,
`achieve the same throughput as a TCP connection.
`
`To develop a comprehensive CM congestion con-
`trol protocol, one can begin by designing a congestion
`control protocol that sets the transmission rate in a
`TCP-friendly manner. Once such a strawman" or
`baseline protocol is designed, it can then be modied
`to support the timeliness requirements of CM data,
`perhaps with some loss of friendliness." The design of
`the strawman" TCP-friendly protocol must be exi-
`ble enough to allow such modications. This require-
`ment for exibility rules out the use of TCP itself as
`the baseline protocol. The congestion control mech-
`
`VIMEO/IAC EXHIBIT 1021
`VIMEO ET AL., v. BT, 2019-00833
`
`Page 1 of 15
`
`

`

`anisms of TCP are tightly coupled with the mecha-
`nisms that provide reliable delivery, an appropriate
`combination for non-real time reliable data transfer,
`but inappropriate for loss-tolerant time-sensitive CM
`applications. In this paper, we propose a simple base-
`line TCP-friendly rate control protocol TFRCP that
`does not couple error-recovery and congestion control,
`and retains sucient exibility for later modications.
`We present a congestion control algorithm that con-
`trols the sending rate in a manner that is roughly
`equivalent to that of TCP. Specically,
`if a TCP
`connection achieves throughput X under given net-
`work conditions and measured over a given interval
`length, then the proposed protocol should also have a
`throughput of X over an interval of the same length
`and under the same network conditions. Note that
`the throughput X has to be measured over some
`time interval, and based on the denition of TCP-
`Friendliness" proposed in  , we assume that this in-
`terval is signicantly larger than the round trip time.
`The actual transmission rate, X, is determined by us-
`ing a model-based characterization of TCP through-
`put in terms of network conditions such as mean round
`trip time and loss rate. We base our protocol on the
`model proposed in  . In   the authors have pro-
`posed a similar approach for multicast congestion con-
`trol, using the formula proposed in  . Our protocol
`diers form theirs in that we use a more accurate char-
`acterization of TCP and unlike   we do not require
`the use of data layering. Other TCP-friendly base-
`line protocols that try to mimic the major features
`of TCP congestion control algorithm without provid-
`ing reliable delivery have been proposed , , , .
`Some ongoing work, based partially on our ideas, with
`a focus on formula-based multicast congestion control,
`is also reported in , . We discuss some of these pro-
`tocols and their limitations in the next section.
`We believe there are several advantages to taking
`a formula-based approach towards developing a TCP-
`friendly congestion control scheme. First, a formula
`based approach is exible. By changing the formula,
`one can easily adjust the performance of the proto-
`col. This feature can later be exploited for making
`the protocol sensitive to the timeliness requirement
`of the media being transported. In addition, if TCP
`and non-TCP ows are treated separately in the net-
`work perhaps using a scheme such as , then the
`formula-based approach can be modied to allow non-
`TCP ows to compete only against one another. Fi-
`nally, in  , it has been shown that such an approach
`is more suitable for multicasting. Thus, a formula-
`
`based approach based on an abstract TCP characteri-
`zation can be viewed as a rst step towards developing
`a comprehensive solution to the problem of congestion
`control for CM ows.
`We evaluate the protocol under various trac con-
`ditions, using simulations and implementation. The
`simulations are used to study the behavior of the
`protocol under controlled conditions. The implemen-
`tation and experimentation involve over exper-
`iments over the Internet, using several machines in
`the US and UK. Our experimental and simulation re-
`sults show that the protocol is fair to TCP and to
`other sessions running TFRCP, and that the formula-
`based approach to achieving TCP-friendliness is in-
`deed practical.
`The rest of this paper is organized as follows. In
`Section II, we present an overview of related work re-
`ported in the literature, followed by a description of
`our protocol and its advantages.
`In Section III, we
`present simulation studies of our protocol. In Section
`IV, we present results from a real-world" implemen-
`tation of the protocol. In Section V we discuss some of
`our design choices. Section VI concludes the paper.
`
`II. Rate Adjustment Protocols
`
`Several TCP-friendly rate adjustment protocols
`have recently been reported in the literature , ,
`,  , . Of these,  ,  are specic to multicast
`applications, while , ,  are unicast oriented. We
`now briey review each of these ve schemes, describe
`the new TFRCP protocol, and show how it overcomes
`some of the limitations of earlier work.
`
`A. Previous Work
`
`In , authors describe a protocol that may be clas-
`sied as a TCP-Exact" approach. They propose a
`protocol which manages its window size in exactly the
`same way as TCP does, but instead of retransmitting
`lost packets, it allows the user to send new data in
`each packet. The principle concern with this protocol
`is its inexibility. Since the protocol strictly adheres
`to TCP window dynamics, it would be hard to modify
`it to take into account timeliness requirements of CM
`data delivery.
`The TCP-friendly protocols reported in  , ,  ,
` are based either explicitly or implicitly on the
`TCP characterization rst reported in   and later
`formalized in  , . This characterization states
`that in absence of timeouts, the steady state through-
`
`Page 2 of 15
`
`

`

`put of a long-lived TCP connection is given by:
`
`Throughput =
`
`C
`
`R pp
`
` 
`
`where C is a constant that is usually set to either
` : or : , depending on whether or not receiver
`uses delayed acknowledgments, R is the round trip
`time experienced by the connection, and p is the ex-
`pected number of window reduction events per packet
`sent. Note that the throughput is measured in terms
`of packetsunit time. Also note that p is not the
`packet loss rate, but is the frequency of loss indica-
`tions per packet sent  . The packet loss rate pro-
`vides an upper bound on the value of p, and may be
`used as an approximation. The key assumption be-
`hind the characterization in   is that timeouts do
`not occur at all. Consequently, it is reported in  
`that   is not accurate for loss rates higher than .
`As the formula does not account for timeouts, it typi-
`cally overestimates the throughput of a connection as
`loss rate increases. Data presented in  ,  shows
`that timeouts account for a large percentage of win-
`dow reduction events in real TCP connections, and
`that they aect performance signicantly.
`In   the authors propose a multicast congestion
`control scheme in which the data is transmitted in a
`layered" manner over dierent multicast groups. The
`more layers a receiver joins, the more data it receives.
`In   the receivers compute round trip times and es-
`timate the packet loss rate p, and use   to compute
`the TCP-friendly" rate at which they should receive
`the data. Based on this estimate, and the knowledge
`of the layering schemes, each receiver can dynamically
`decide to join or leave certain multicast groups to ad-
`just the rate at which it receives the data. In , the
`authors propose a similar scheme in which the layers
`have data rates that are xed multiples of a base rate,
`and a TCP-like eect additive increase, multiplica-
`tive decrease is achieved by using strict time limits
`on when a receiver might join or leave a group. The
`analysis of the algorithm yields a throughput charac-
`terization that is similar to  . Apart from not being
`TCP-friendly at loss rates above , both schemes
`rely on data layering, which is not easy to achieve for
`all types of CM encodings. In addition, determining
`round trip times in a multicast setting is a dicult
`task, as noted in  .
`In  the authors propose a scheme that is suitable
`mainly for unicast applications, but may be modied
`for multicast applications. The scheme relies on reg-
`ular RTPRTCP reports   sent between the sender
`
`and the receiver to estimate the loss rate and round
`trip times. In addition, they propose modications to
`RTP that allow the protocol to estimate the bottle-
`neck link bandwidth using the packet-pair technique
`proposed in  . An additive increasemultiplicative
`decrease scheme based on these three estimates loss
`rate, round trip delay, and bottleneck bandwidth is
`then used to control the sending rate. The scheme
`has several tunable parameters whose values must
`be set by the user.
`In addition, the scheme is not
`provably" TCP-friendly, although TCP-friendliness
`is evidenced in the few simulations reported in the
`paper.
`In   the authors propose an additive in-
`creasemultiplicative decrease rate control protocol
`that uses ACKs in a manner similar to TCP to es-
`timate round trip times and detect lost packets. The
`rate adjustment is done every round trip time. The
`authors also propose to use the ratio of long-term and
`short-term averages of round trip times to further ne
`tune the sending rate on a per-packet basis.
`Although the protocols reported in  and   do
`not explicitly use   to control their rates, the work
`in  , ,  has shown that the relationship between
`loss rate and the throughput of these protocols will be
`similar to  . As a result, these protocols will not be
`TCP-friendly" at loss rates higher than . While
` ignores this problem, in   the authors mention
`that their work is targeted towards a future scenario
`in which SACK TCP   and RED  switches will be
`widely deployed, reducing the probability of timeouts.
`However, in the present Internet, TCP-Reno   is
`the predominant protocol and very few RED switches
`have been deployed.
`In the next section we propose a new protocol that
`achieves TCP friendliness in a more real world" sce-
`nario that includes competing TCP-Reno connections,
`drop-tail switches and diverse background trac con-
`ditions.
`
`B. The TFRCP Protocol
`
`The TFRCP protocol is a rate-adjustment conges-
`tion control protocol that is based on the TCP char-
`acterization proposed in  . Unlike  , , , the
`characterization in   takes into account the eects
`of timeouts, a consideration that is particularly im-
`portant when TCP-Reno one of the most widely de-
`ployed versions of TCP is used with drop-tail routers,
`which tend to produce correlated losses.
`If a TCP-
`Reno connection encounters correlated losses, it tends
`to experience a signicant number of timeouts  . In
`  the authors quantify this phenomenon and its ef-
`
`Page 3 of 15
`
`

`

`fects on throughput. The resulting analytic charac-
`terization of TCP throughput can stated as follows:
`
`
`
`Throughput  f Wmax; R; p; B
`where throughput is measured in packets per unit
`time, Wmax is the receiver’s declared window size, R
`is the round trip time experienced by the connection,
`p is the loss rate or, more accurately, the frequency
`of loss indications per packet sent and B is the base
`timeout value  . A complete statement of the for-
`mula is presented in the Appendix.
`There are two parts to the TFRCP protocol: a
`sender-side protocol and a receiver-side protocol. The
`sender-side protocol works in rounds of duration M
`time units. We call M the recomputation interval. At
`the beginning of each round, the sender computes a
`TCP-friendly rate we will shortly describe this com-
`putation in detail, and sends packets at that rate.
`Each packet carries a sequence number and a times-
`tamp indicating the time the packet was sent. The re-
`ceiver acknowledges each packet, by sending an ACK
`that carries the sequence number and timestamp of
`the packet it is acknowledging. Consider an ACK for
`a packet whose sequence number is k. In addition to
`the sequence number and the timestamp, the ACK
`also carries a bit vector of  bits indicating whether
`or not each of the previous  packets k (cid:0)  : : : k was
`received. The sender processes these ACKs to com-
`pute sending rate for the next round. Note that each
`packet is ACKd eight times, providing some protec-
`tion against ACK losses.
`Let us now consider the sending rate computation
`in detail. Consider round i. Let ri be the sending rate
`for this round, R be the the current round trip time
`estimate, and B be the estimate of the base timeout
`value. The number of packets to be sent in this round
`is ni = ri M . The ni packets are clocked out uni-
`formly during the round . As noted earlier, packets
`carry a sequence number and a timestamp indicating
`the time the packet was sent. The sender keeps a
`log of all packets it has sent in this round. The log
`contains two entries for each packet. The rst entry
`indicates whether the packet has been i received and
`has been acknowledged by the receiver; ii presumed
`lost; iii of unknown status neither ACKd nor yet
`presumed lost. We call this the received status" of
`the packet. The second entry consists of a value that
`
` In simulation studies, it is possible clock out packets evenly
`over the entire duration of the round. This is not possible in
`actual implementation, due to limited accuracy of timers. We
`discuss this further in Section IV.
`
`is equal to the time the packet was sent plus the cur-
`rent base timeout value. We call this the timeout
`limit" for the packet.
`As the sender sends packets, it also receives ACKs
`from the receiver. Consider an ACK carrying se-
`quence number k that is received by the sender at
`time tk. Let the timestamp carried by the ACK be
`sk. The sender updates the lostreceived status of
`packets k (cid:0)  : : : k using the bit vector available in
`the ACK. The sender also updates the round trip time
`estimate R and base timeout B using the dier-
`ence tk (cid:0) sk. This update is done exactly as in TCP;
`see  for the details of the computation. At the end
`of the ith round, the sender computes ri+ as follows:
`Let the current time be ti. Let j be the packet
`with the smallest sequence number, whose received
`status was unknown" at the end of round i (cid:0) , l
`be the last packet sent and a be the highest sequence
`number for which we have received an ACK. Then any
`packet whose sequence number lies between j and l,
`both included and whose timeout limit is less than
`ti, is marked as lost. Also, any packet whose sequence
`number lies between j and a both included, and
`whose received status is unknown" is marked as lost.
`Let xi be the number of packets marked as received"
`between j and a, and let yi be the number of packets
`marked as lost" between j and a. Then:
` If yi = , then no packets were lost and:
`
`ri+ =  ri
`Hence, when no packets are lost in a round, packets
`are sent twice as fast in the next round. We will dis-
`cuss this feature more in Section V.
` Otherwise, yi = . Let pi = yi
`. In this case, the
`rate for round i + is
`
`xi+yi
`
`ri+ = f Wmax; R; pi; B
`
`where f is dened in . It is here that the analytic
`characterization in   comes into play.
`The starting value r, can be set to any reasonable
`value. We have found that for suciently long ows,
`and for reasonable values of M , the value of r has lit-
`tle impact on the performance of the protocol. For all
`simulations and experiments described in this paper,
`we set this value to  packetssecond. The initial
`values of R and B are set in a manner similar to TCP
`.
`TFRCP has no built-in error recovery mechanisms.
`When a comprehensive congestion control protocol,
`based on TFRCP is developed, the applications will
`
`Page 4 of 15
`
`

`

`be able to choose an error control strategy that is
`appropriate for the given media type. An important
`feature of any transmission control protocol is self-
`limitation"  . This means that if the protocol starts
`experiencing  or near  losses, its sending
`rate should be reduced to almost zero. TCP achieves
`this via timeouts and eventual closedown of the con-
`nection. The TFRCP protocol uses the model pro-
`posed in  , which takes into account the eect of
`timeouts and automatically reduces the sending rate
`to very small values at high loss rates.
`The key question is how frequently the sender
`should re-compute the rate, i.e., how to determine the
`value of M . In the following section we use simula-
`tions to explore various strategies for choosing M , and
`their impact on the performance of the protocol.
`
`III. Simulation Results
`
`In this section we present simulation studies of the
`TFRCP protocol. The simulations are used to study
`the behavior of the protocol under controlled con-
`ditions.
`In the following section we present addi-
`tional studies carried out over the Internet. We have
`used the ns simulator   for our simulations. There
`are two main challenges for any simulation study of
`this nature: rst, how to select appropriate network
`topologies and how to eectively model the back-
`ground trac and second, how to dene and measure
`appropriate performance metrics. Several diculties
`in this regard are pointed out in  . Thus, before we
`present any simulation results, we discuss our simula-
`tion topology and our performance metrics.
`
`A. Simulation Topology
`
`In our simulations, we use a simple topology to un-
`cover and illuminate the important issues; our exper-
`iments with TFRCP over the Internet test its use in
`real-world" scenarios. The simulated network topol-
`ogy assumes a single shared bottleneck link, as shown
`in Figure . The sources are arranged on one end of
`the link and the receivers on the other side. All links
`except the bottleneck link are suciently provisioned
`to ensure that any dropsdelays that occur are only
`due to congestion at the bottleneck link. All links
`are drop-tail links. Many previous studies  , , ,
` have used similar topologies.
`The problem of accurately modeling background
`trac is more dicult. We consider three types of
`background trac: innite-duration FTP-like connec-
`tions, medium-duration FTP -like connections and
`self-similar UDP trac. The innite-duration FTP
`
`Bottleneck Link
`
`Senders
`
`Receivers
`
`Fig. . Simulation Topology
`
`connections allow us to study the steady-state be-
`havior of our protocol. Medium-duration FTP con-
`nections introduce moderate uctuations in the back-
`ground trac. Finally, self-similar UDP trac is be-
`lieved to be a good model for short TCP connections
`such as those resulting from web trac  , .
`When multiple TCP connections are simulated over
`a single bottleneck link, the connections can become
`synchronized. We take two measures to prevent such
`synchronization. First, we start the connections at
`slightly dierent times. Second, before each packet is
`sent out, a small random delay is added to simulate
`processing overhead. These measures are applied to
`both TCP and TFRCP connections.
`
`B. Performance Metrics
`
`Recall that we view TFRCP protocol as only a rst
`step towards developing a comprehensive congestion
`control protocol for CM data ows. Thus, we are
`only interested in measuring the TCP-friendliness"
`of the TFRCP protocol. We dene the friendliness"
`metric as follows. Let kc denote the total number
`of monitored TFRCP connections and kt denote the
`total number of monitored TCP connections. We de-
`note the throughput of the kc TFRCP connections
`
`
` ; : : : T cby T c ; T c
`kc and that of the TCP connections by
`
`
`T t ; T t; : : : T t
`kt respectively. Dene:
`TT = Pkt
`TC = Pkc
`i= T t
`i= T c
`i
`i
`kc
`kt
`
`and
`
`The performance metric of interest is the friendliness
`ratio", F :
`
`F = TC =TT
`
`Another metric for measuring performance is the
`equivalence ratio", E:
`
`E = maxTT =TC ; TC =TT 
`
`Page 5 of 15
`
`

`

`Note that the value of E is always  . E gives a
`better visual representation of the closeness of the
`throughputs achieved by the two protocols. How-
`ever, this metric will distort any trend that might be
`present in the ratio of the two throughputs as we vary
`various parameters. For example, a decreasing value
`of F as a function of some system parameter will not
`always result in a decreasing value of E: Thus, we use
`F as the fairness metric whenever we are interested
`in trends, and use E otherwise. It is also important
`that the TFRCP connections achieve fairness amongst
`themselves. We dene the ratio:
`
`F C =
`
`max ikc T c
`i
`min ikc T c
`i
`
`to characterize the fairness achieved among the
`TFRCP connections.
`
`C. Simulation Scenarios
`
`We now present results of performance evaluation
`of TFRCP protocol in various simulation scenarios.
`
`C. Long duration ows with constant bottleneck
`bandwidth
`
`In this scenario we consider trac made up entirely
`of equal numbers of innite-duration TCP connec-
`tions and innite-duration TFRCP connections. All
`connections always have data to send. All connec-
`tions start at the beginning of simulation and last
`until the simulation ends. The aim here is to study
`steady state behavior of TFRCP protocol. If TFRCP
`performs well i.e., in a TCP-friendly manner, the
`TCP and TFRCP connections should see approxi-
`mately the same throughput.
`We vary the total number of ows in the net-
`work between and . Half of these connec-
`tions are TCP connections and the rest are TFRCP
`connections. The initial sending rate, r,
`for all
`TFRCP connections was set to approximately 
`packetssecond. The bottleneck bandwidth is held
`constant at .Mbps, and the bottleneck delay is set
`to ms. This roughly simulates a situation in which
`a number of connections share a T link. As the num-
`ber of ows grows, the window sizes of individual TCP
`connections shrink, increasing the probability of time-
`outs.
`In such circumstances, the congestion control
`protocols proposed in  ,  are not be able to guar-
`antee fairness.
`We consider three dierent ways to determine how
`frequently TFRCP should recompute its rate:
`
` Fixed recomputation interval, i.e. we use a xed
`value for M . We call this strategy S .
` The recomputation interval is a xed multiple of
`round trip time. If at the beginning of round i the
`round trip time is rtti, then the next recomputation
`is performed after K rtti time units, where K is
`constant. We call this strategy S.
` The recomputation interval is calculated at the be-
`ginning of each round, and is set to sum of two num-
`bers, one of which is a constant while the other is cho-
`sen from a uniform random distribution. This strat-
`egy will further prevent TFRCP connections from
`synchronizing with each other. We call this strategy
`S .
`In Figure a we present simulation results for the
`case in which the TFRCP protocol uses strategy S ,
`with ve values of M between  and  seconds. The
`length of each simulation was seconds, and the
`throughput of all connections was measured at the
`end of the simulation. Each data point is an aver-
`age of three experiments.
`It can be seen that with
`steady state background trac, the protocol is able
`to maintain a friendliness ratio close to .
`In Figure b we present simulation results when
`TFRCP protocol uses strategy S, with four values
`of K between and . We notice that as the load
`on the network increases, the resulting TFRCP be-
`havior is more aggressive than TCP. As the load on
`the network increases, the round trip time experienced
`by each ow also increases. As a result, each TFRCP
`ow re-computes its rate less frequently. TCP reduces
`its transmission rate multiplicatively every time it en-
`counters a loss, and increases it only additively in case
`of no loss, thus the slowness of response of TFRCP
`ows to react to losses hurts the throughput of TCP
`connections. Thus TFRCP is more aggressive, and
`clearly S is not an appropriate strategy for deciding
`recomputation intervals.
`In Figure c we present simulation results where
`TFRCP protocol uses strategy S . For each line we
`use a dierent constant and a dierent uniform ran-
`dom distribution: : + ; :; : + ;  and : +
`; :. For this simulation study, all TFRCP connec-
`tions were started simultaneously. It can be seen that
`in this third case the protocol is able to maintain a
`friendliness ratio close to .
`We have performed simulations with other bottle-
`neck delays and observed similar results. In the rest
`of this section we only present results using strategy
`S . We do this for two reasons. First, strategy S
`is the simplest strategy. The goal of this paper is to
`
`Page 6 of 15
`
`

`

`Constant Bottleneck Bandwidth:S2
`
`K=10
`K=20
`K=30
`K=60
`
`10
`
`15
`
`20
`
`25
`
`30
`Total Flows
`
`35
`
`40
`
`45
`
`50
`
`01234567
`
`Friendliness (F)
`
`Constant Bottleneck Bandwidth: S1
`
`M=2 sec
`M=3 sec
`M=4 sec
`M=5 sec
`
`3
`
`2.5
`
`2
`
`1.5
`
`1
`
`0.5
`
`Friendliness (F)
`
`0
`
`10
`
`15
`
`20
`
`25
`
`30
`Total Flows
`
`35
`
`40
`
`45
`
`50
`
`a Strategy S
`
`b Strategy S
`
`Constant Bottleneck Bandwidth, S3
`
`0.3+[0, 5.4]
`1.5+[0, 3]
`2.7+[0, 0.6]
`
`15
`
`20
`
`25
`
`30
`Total Flows
`
`35
`
`40
`
`45
`
`50
`
`c Strategy S
`
`3
`
`2.5
`
`2
`
`1.5
`
`1
`
`0.5
`
`0
`
`10
`
`Friendliness (F)
`
`Fig. . Constant Bottleneck bandwidth, Bottleneck Delay ms
`
`present TFRCP protocol as a baseline policy; use of
`a simple policy to decide the recomputation interval
`is consistent with that goal. Second, the question of
`selecting the appropriate recomputation interval re-
`quires more complex answers than the three simple
`strategies described here. The recomputation interval
`must be short enough to allow TFRCP to be respon-
`sive, while at the same time it must be large enough
`to allow the loss rate measurements to be meaningful.
`This question is currently under research , . Thus,
`it is appropriate to restrict the baseline protocol de-
`scribed here to the simplest strategy.
`Recall that the TFRCP connections should be fair
`to each other as well. In Figure we plot the value
`of F C when the TFRCP protocol uses strategy S .
`It can be seen that the TFRCP protocol achieves ac-
`ceptable fairness among TFRCP connections in most
`
`cases.
`
`C. Long duration ows with constant bottleneck
`bandwidth share
`
`In this scenario, the trac is made up of innite-
`duration TCP connections and innite-duration
`TFRCP connections. All connections start at the be-
`ginning of the simulation and last until the end. We
`vary the total number of ows in the network between
` and . The bottleneck bandwidth is computed by
`multiplying the total number of ows by Kbps. The
`buer size at the bottleneck link was set in each case
`to four times the bandwidth-delay product. These set-
`tings of packet and buer sizes allow the TCP connec-
`tions to have reasonable" window sizes   and ex-
`hibit the full range of behavior such as slow start and
`congestion avoidance. Each experiment is repeated
`
`Page 7 of 15
`
`

`

`bottleneck link bandwidth is set to .Mbps and the
`bottleneck delay is set to ms. The duration of sim-
`ulation is seconds. The amount of data trans-
`ferred by each background connection is chosen from
`a uniform distribution. The interarrival times for the
`medium-duration FTP connections are chosen such
`that on average a constant number of background con-
`nections will be active. A higher average number of
`background connections leads to more uctuations in
`the background trac, and in addition, the window
`size of each TCP connection tends to be smaller due
`to a smaller bandwidth share, increasing the possi-
`bility of timeouts. We are interested in the perfor-
`mance of TFRCP protocol as the average number of
`background connections change. For graphs in Fig-
`ures a and b the data transferred by each con-
`nection is chosen from ; KB average KB and
`; KB average KB, respectively.
`The results in Figure  show that TFRCP main-
`tains a friendliness ratio of approximately one with
`a recomputation interval M =  seconds. The ra-
`tio decreases as the recomputation interval becomes
`larger. We conjecture that this behavior is due to the
`nature of the background trac. As old connections
`terminate and new ones start, there are small periods
`of time during which the background trac decreases
`slightly as the new connections go through their slow
`start phase. TCP is better able to take advantage of
`these small drops in the background trac, due to its
`faster feedback mechanism. The TFRCP connection
`changes its sending rate only every M seconds, and
`hence is unable to take advantage of short-term drops
`in the background trac.
`
`C. ONOFF UDP trac
`
`In this simulation scenario, we model the eects
`of competing web-like trac very small TCP con-
`nections, some UDP ows. It has been reported in
`  that WWW-related trac tends to be self-similar
`in nature. In , it is shown that self-similar traf-
`c may be created by using several ONOFF UDP
`sources whose ONOFF times are drawn from heavy-
`tailed distributions such as the Pareto distribution.
`Figure  presents results from simulations in which
`the shape" parameter of the Pareto distribution is
`set to .. The mean ON time is second and the
`mean OFF time is  seconds. During ON times the
`sources transmit with a rate of Kbps. The numbe