Simulation-based Performance Comparison of
`TCP-Friendly Congestion Control Protocols
`
`fsuhaidijmourad@scs.leeds.ac.ukg
`
`Suhaidi Hassan and Mourad Kara
`School of Computer Studies
`University of Leeds, Leeds LS2 9JT
`United Kingdom
`
`http://www.scs.leeds.ac.uk/atm-mm
`
`Abstract
`
`The main purpose of the rate-based congestion
`controlprotocolsthathavebeendevelopedtosup-
`port the deployment of real-time multimedia ap-
`plications in the Internet is to ensure that the ap-
`plication’strafficsharethenetworkinafairlyand
`friendlymannerwiththedominantTCPtraffic.In
`this work we use the network simulator ns-2 to
`evaluatethe performanceof tworate-basedTCP-
`friendly(TF)congestioncontrolprotocols,name-
`ly Rate Adaptation Protocol (RAP) and TCP-
`Friendly Rate Control Protocol (TFRC). We de-
`vise a simple method to characterise friendliness
`andusethismethodtocomparetheresultstoeach
`otherandstudytheirbehaviourundervariousnet-
`work scenarios. Our main goal for these experi-
`ments is to evaluate these two protocols and de-
`termine which is the best rate-based protocol to
`support our future work in end-to-end quality of
`service (QoS) support for streaming multimedia
`applications. We discover that TFRC works bet-
`terinmostofourexperiments.
`
`1
`
`Introduction
`
`The real-time dissemination of continuous audio
`and video data via real-time streaming multime-
`
`dia applications accounts for a significant, and in-
`creasing portions of the Internet traffic. Such ap-
`plications include packet voice, video and multi-
`cast bulk data transport. These applications pro-
`duce traffic that must coexist and share Internet
`resources with the majority of traffic comprising
`TCP flows.
`In addition, they require real-time
`performance guarantees such as bounded delay
`and minimum bandwidth. Therefore, supporting
`these traffic over heterogeneous multi-protocol
`networks such as the Internet is not a trivial task.
`
`Most of these real-time applications are non-
`TCP-based, they are usually not built with ad-
`equate congestion control, mainly for simplicity
`reason. These applications produce traffic flows
`that are considered unresponsive with respect to
`the congestion control mechanisms deployed in
`the network. Widespread deployment of these
`traffic in the Internet threatens fairness to compe-
`ting TCP traffic and may lead into possible con-
`gestion collapse [7]. Congestion collapse is a si-
`tuation where although the network links are hea-
`vily utilised, very little useful work is being done,
`and packets transmitted will simply be discarded
`before reaching their final destinations [5].
`
`The problem arises because the non-TCP-based
`traffic does not respond to congestion signals
`which cause TCP flows to back off, resulting in
`
`1
`
`VIMEO/IAC EXHIBIT 1022
`VIMEO ET AL., v. BT, IPR2019-00833
`
`

`

`an unfair bandwidth share. Several approaches
`have been proposed to overcome this problem.
`One approach is through the provision of differ-
`entiated service class [16] where streaming ap-
`plications are supported via higher priority class.
`Another proposed solution is by utilising mecha-
`nisms such as scheduling and service disciplines
`[23, 12], resource reservation [4] and admission
`control [13], however these approaches are com-
`mon in guaranteed-service networks such as ATM,
`but unfortunately not in the Internet environment.
`Yet another possible approach to overcome the un-
`fairness problem is by deploying end-to-end con-
`gestion control mechanisms within such applica-
`tions, making them adaptive to the network con-
`ditions. Since dominant portion of today’s Inter-
`net traffic is TCP-based, such congestion control
`mechanisms must be TCP-friendly. These TF ap-
`plications must send their data at a rate no higher
`than that of a TCP connection, operating along the
`same path [14] thus obtaining approximately the
`same average bandwidth over the duration of con-
`nection as TCP traffic.
`Recently, several unicast TF rate-based con-
`trol protocols have been proposed such as in
`[21, 11, 20, 10, 19]. In these works however, the
`authors often perform performance evaluation of
`their work only. Work on comparing performance
`of two or more rate-based congestion control pro-
`tocols is somewhat limited. In this paper, we com-
`pare the performance of two of these protocols
`namely the Rate Adaptation Protocol (RAP) [20]
`and TCP-Friendly Rate Control Protocol (TFRC)
`[10]. Our comparison is based upon the results ob-
`tained from running various experiments using the
`network simulator ns-2 [1].
`Our main goal of this work is to explore TCP
`friendliness of RAP and TFRC particularly the
`effects on TCP-friendliness when using different
`network scenarios and TCP implementations. We
`are interested in one-to-one performance compa-
`rison of the TF protocols with their TCP peer.
`We believe that this one-to-one comparison would
`give a clearer picture of their TCP-friendliness.
`The evaluation is important in order to understand
`the behaviour of these two protocols operating un-
`
`der certain network conditions. In other words, we
`intend to determine which of these two rate-based
`protocols is the best in terms of TCP-friendliness.
`This paper is organised as follows. In Section 2,
`we present a brief background and description of
`the TF rate-based control protocols and introduce
`the two protocols under study. We describe the ex-
`perimental design and its rationale in Section 3. In
`Section 4, we discuss the experiments and subse-
`quently evaluate the performance of these two pro-
`tocols under different scenarios. Section 5 gives a
`conclusion.
`
`2 Background and Related
`Works
`
`2.1 TCP-Friendly Rate-based Con-
`trol Protocols
`
`As most real-time streaming multimedia applica-
`tions are based upon UDP which does not employ
`congestion control mechanisms, they might seize
`most of the shared bottleneck bandwidth, thus
`starving the TCP connection. This problem ap-
`pears because the UDP traffic does not respond to
`congestion signals which cause TCP flows to back
`off. The UDP traffic continues to dominate the
`bandwidth which negatively affect the throughput
`of the other ’good’ network citizen. This is a clas-
`sic example of TCP-unfriendliness [7]. To over-
`come this problem, it is crucial for such appli-
`cations to employ TF congestion control mecha-
`nisms.
`In addition, since these type of applications are
`rate-based, it is more appropriate to utilise the
`rate-based congestion control mechanism. In the
`rate-based congestion control scheme, the source
`does not use congestion window (as in window-
`based TCP) to control the amount of data in the
`network.
`Instead, the source directly adjusts its
`sending rate based on what is appropriate for the
`applications.
`The rate-based source constantly monitors
`overall packet loss in the network while sending
`data. Monitoring is normally done by means of
`
`2
`
`

`

`Th gh =k R 
`
`loss feedback sent by the receiver. The source
`then calculates the rate and sends the data appro-
`priately. In order to be TCP-friendly, the source’s
`average sending rate must not be higher than that
`achieved by a TCP connection along the same
`path. Estimation of the steady state throughput
`of a long live TCP connection, in the absence
`of timeouts, as proposed by [14, 15, 8] is given by:
`
`(1)
`with k as constant (1.22 or 1.31), depending on
`the acknowledgement type used, M as Maximum
`segment (packet) size, R as round trip time expe-
`rienced by the connection and l as probability of
`loss [19] (during the lifetime of the connection).
`From this equation we know that the throughput
`is inversely proportional to the round trip time and
`the square root of loss probability. Hence we give
`special attention to these two parameters in this
`work. In the following subsection, we discuss the
`two TF protocols under study.
`
`2.2 Rate Adaptation Protocol (RAP)
`
`RAP [20] was developed by Rejaei et. al. at the
`University of Southern California as part of an
`end-to-end quality of service architecture. RAP
`is a loss-based mechanism. It detects congestion
`based on packet losses, as in TCP. Packet loss-
`es are determined when there are gaps in the se-
`quence number of the transmitted packets as well
`as when transmission timeouts occur. Due to the
`fact that real-time streaming applications are es-
`sentially semi-reliable, RAP decouples congestion
`control and error control, leaving the application
`layer to deal with the latter. The receiver module
`observes these gaps and notifies the sender accord-
`ingly.
`RAP estimates the round-trip time (RTT) called
`SRTT, and computes the timeouts based on Ja-
`cobson/Karel’s algorithm.
`The protocol utili-
`ses the Additive Increase Multiplicative Decrease
`(AIMD) approach to emulate the TCP behaviour
`in rate-based environment, and this is important
`for obtaining a fair share of the bottleneck band-
`width. Using this approach the source’s sending
`
`3
`
`rate is increased additively and repeatedly when
`there is no congestion, but when congestion oc-
`curs, it decreases the rate instantly in multiplica-
`tive order. The source’s sending rate is changed by
`reducing the gap between the transmitted packet-
`s, which consequently increases the transmission
`rate.
`There are two types of rate adaptation employed
`by RAP; coarse grain and fine grain adaptation.
`In coarse grain (CG) adaptation, RAP merely us-
`es AIMD approach for rate adjustment.
`In fine
`grain (FG) adaptation however, RAP uses a feed-
`back signal based on the ratio of the short-term ex-
`ponential moving average of RTT to a long-term
`exponential moving average of RTT, in addition
`to AIMD. The use of fine grain adaptation is in-
`tended to make RAP more stable and responsive
`to transient congestion. In this paper, we use both
`types of RAP adaptation granularities for compar-
`ison against the other protocol under study.
`
`2.3 TCP-Friendly Congestion Con-
`trol Protocol (TFRC)
`
`TFRC [10] is a rate-based end-to-end conges-
`tion control protocol which is intended for uni-
`cast playback of Internet streaming applications.
`It was developed at AT&T Center for Internet Re-
`search at UC Berkeley (ACIRI) by Floyd et. al.
`TFRC is a sender-based scheme that works by
`continuously adjusting the source’s sending rate
`based on equation (1). TFRC protocol is still un-
`der development and its ns simulator code is made
`available in the ns simulator version 2.1b6 or later.
`As with RAP, TFRC is source- and loss-based
`rate control protocol. The sender is to adjust its
`transmission rate based on observed loss rate and
`RTT. The adjustment of sending rate to achieve
`TCP-friendliness is based upon the TCP through-
`put model described in [17, 8, 18]. Similar to RAP,
`TFRC uses AIMD to emulate the TCP for a coarse
`grained behavior and utilises exponential filter to
`maintain the fine time granularity. However, the
`sender implicitly uses the two approaches in all
`rate calculations.
`The sender uses the slow start technique at the
`
`

`

`scheme. From the table, we consider F = 1.00 as
`We regard the value F> 4.00 as very poor or very
`width. We consider the value F< 0.25 as very
`(cid:15) Router policy.
`(cid:15) Bottleneck delay. A smaller bottleneck delay
`
`Table 1 shows our proposed characterisation
`
`the excellent value to indicate that the bottleneck
`bandwidth is fairly shared among the competing
`TCP and TF flows. In this case both TCP and TF
`flows obtain about 50% of the bottleneck band-
`width. As TCP bandwidth decreases below this
`point, the TF flows obtain more bandwidth result-
`ing unfriendliness on behalf of TF flows towards
`that of TCP. This situation could continue until TF
`flows monopolise almost all available bandwidth.
`
`TCP-unfriendly. Similarly, as the TCP flows ob-
`tain more bandwidth beyond this optimum 50-50
`point, the value of Fr decreases linearly to a point
`where TCP flows conquer all the available band-
`
`poor or very TF-unfriendly.
`
`3.2 Scope of Comparison
`
`As generally known, simulations involving TCP
`normally have to deal with the wide range of vari-
`ables, environments and implementation flavours
`(or variants). This causes difficulty in isolating a
`particular variable and studying its relation with a
`particular parameter because of inter-dependency
`among these variables. To minimise the related
`problems, we limit our scope of comparison to
`those related only to the following experiments:
`
`In this set of experiments
`we use Random Early Detection (RED) [9]
`policy as comparison to the normal Drop-
`Tail (First-In-First-Out/FIFO). RED policy is
`known for its ability to evenly distribute the
`losses across the competing flows and avoid
`buffer overflow over a wide range. The un-
`fairness due to burstiness of TCP flow is eli-
`minated by RED router. In the related exper-
`iments, we would like to explore the effects
`of using RED router on TCP friendliness of
`these protocols.
`
`indicates a smaller round-trip time. Connec-
`tions become more aggressive and achieve
`
`beginning of transmission phase during which it
`tries to multiplicatively increase its sending rate
`at every RTT until it detects a loss. Packet losses
`are identified by gaps in the sequence number of
`the transmitted packet at the receiver module, as
`in RAP. The receiver sends feedback to the sender
`at regular intervals. The sender then adjusts the
`rate accordingly based on this feedback. When the
`receiver notices the loss, it immediately notifies
`the sender and the sender adjusts its sending rate
`based on the TF equation (1).
`
`3 Experimental Design
`
`3.1 Description of Experiments and
`Rationale
`
`The main objective of this work is to compare
`the performance of RAP and TFRC in terms of
`their friendliness towards the competing TCP traf-
`fic flows under various network conditions. Speci-
`fically, we investigate how the throughput of the
`flows are affected as a result of the rate adjust-
`ment process performed by the TF sources when
`competing with their TCP counterparts in dif-
`ferent network scenarios. In doing this, we mea-
`sure the throughput of each rate-based and TCP
`flows respectively and calculate the average bot-
`tleneck bandwidth share of each flow based on
`their average throughput. We determine the de-
`gree of friendliness (i.e. fairness) of the TF rate-
`based protocols by comparing their average band-
`width share against that of the TCP flows.
`
`expressed as:
`
`(2)
`
`Simply stated, the friendliness ratio, F an be
`F=T T
`where T is the average throughput of the TF
`flows and T is the throughput of the TCP flows.
`of our experiments. Using the value of F, we pro-
`ness metric. Since F is always inversely propor-
`
`In addition, we need a way to interpret the results
`
`pose a simple method to characterise the friendli-
`
`tional to the percentage bandwidth share obtained
`by TCP flow, we can use this percentage as an in-
`dicator for our purpose.
`
`4
`
`

`

`Approx. TCP Bandwidth Share (%)
`
`Characterization
`
`Less than 20
`20 - 29
`30 - 39
`40 - 49
`˜ 50
`51 - 59
`60 - 69
`70 - 79
`More than 80
`
`2.34 - 4.00
`1.51 - 2.33
`1.04 - 1.50
`
`0.69 - 0.96
`0.44 - 0.68
`0.25 - 0.43
`
`Very Poor
`Poor
`Unsatisfactory
`Satisfactory
`Excellent
`Satisfactory
`Unsatisfactory
`Poor
`Very Poor
`
`Table 1: Characterizing TCP-friendliness
`
`F
`> 4.00
`0.97(cid:20) 1.00(cid:20) 1.03
`< 0.25
`(cid:15) TCP Reno. Currently, most Internet traffic is
`(cid:15) TCP with
`
`(cid:15) Bottleneck bandwidth. TCP uses Additive In-
`(cid:15) Loss rate. The use of equation (1) in control-
`
`larger share of bandwidth with shorter RTT.
`It is also obvious that a TCP connection with
`shorter delay can update their window sizes
`faster than those with longer delays, thus cap-
`ture higher bandwidth. A good TF protocol
`must respond to this condition appropriately.
`
`crease Multiplicative Decrease (AIMD) algo-
`rithm. At a smaller bottleneck bandwidth,
`TCP losses become more dominant,
`thus
`TCP deviates from the AIMD algorithm -
`paving the way for non-TCP applications to
`get bigger share of the bandwidth. Again, a
`good TF protocol must react to this condition
`so that it will not monopolise the available
`bandwidth.
`
`ling the sender’s rate warrants that at loss rate
`higher than 5%, a rate-based control proto-
`col like RAP will still be TCP-friendly. RAP,
`however does not explicitly use (1) to control
`its rate. In these set of experiments, we inves-
`tigate the effect of increasing loss rate on the
`performance of these protocols.
`
`Evaluation of TF protocol behaviour includes
`comparing the average bandwidth share obtained
`by both protocols when competing with TCP, res-
`pectively under different scenarios. For effective
`evaluation, we carefully choose the TCP imple-
`mentation flavors that run with each of the rate-
`based protocol as competing flow, as recommen-
`
`5
`
`ded in [2]. We compare the performance of the
`rate-based protocols against these TCP implemen-
`tations. Our choice of TCP implementations are as
`follows:
`
`Reno-based [22]. Due to this fact, we feel
`that it is important for us to evaluate the per-
`formance of TF protocols against Reno.
`In
`addition, Reno includes fast recovery, where
`the current congestion windows is ’inflated’
`by the number of duplicate ACKs the TCP
`sender has received before receiving a new
`ACK. The constant update of window size
`causes periodic oscillation in window size
`which in turn affect the round trip delay of the
`packets. This may consequently influence the
`way TCP Reno captures the available band-
`width. This may have impact on the friend-
`liness towards competing TF protocols. We
`evaluate TCP Reno against TF protocols in
`the respective experiments.
`
`Selective Acknowledgement
`(SACK) [6]. TCP Sack is designed to over-
`come the problem of poor performance when
`multiple packets are lost from one window of
`data. It allows the TCP sender to intelligently
`transmit only those segments that have been
`lost.
`In addition, it decouples the determi-
`nation of which segment to transmit from
`the decision about when it is safe to re-send
`a packet. The retransmission behaviour of
`
`

`

`TCP Sack may affect the way TF protocols
`adjust their transmission rate which in turn
`affect the friendliness metric. We shall see
`the results of these experimentations.
`
`3.3 Simulation Scenario
`
`We have used the simulator ns-2 [1] from the
`VINT project at U.C. Berkeley/LBNL to perform
`our simulation experiments. The simulator is
`event-driven and runs in a non-real-time fashion.
`In ns-2, the user defines arbitrary network topolo-
`gies which composed of nodes, routers, links and
`shared media. A rich set of protocol objects can
`then be attached to nodes, usually as agents. For
`this simulation, we use several flavors of TCP
`(Reno and Sack), as well as the simulated TF pro-
`tocols. Correspondingly, the user may choose bet-
`ween various types of applications. In this simu-
`lation, we use the FTP application for the TCP
`agent and application using a constant bit rate
`(CBR) traffic pattern, which use the UDP transport
`protocol. We configure the routers using DropTail
`(First-In-First-Out/FIFO) and Random Early De-
`tection (RED) policies. Packet losses are simula-
`ted by packet drops at overflowed router buffer.
`Figure 1 illustrates the simulated scenario used
`in this simulation. We use 2 sets of (n+1) com-
`
`peting sources, where 0(cid:20)n(cid:20)1. One set of these
`TCP Reno or Sack. The TF source TFs send-
`the receiver/sink agent TFr.
`source TCPs sends data to (and receives acknow-
`ledgments from) TCPr receiver agent.
`
`sources act as TF rate-based sources (either RAP
`or TFRC) transmitting TF traffic into the net-
`work, and another set running as TCP agents with
`
`s data to (and receives acknowledgments from)
`Similarly, TCP
`
`10Mbps;
`6 ms
`
`TFsn
`•••
`
`TFs0
`
`TCPsn
`•••
`
`TCPs0
`
`Router
`
`Bottleneck link
`1.5Mbps; 20 ms
`
`Router
`
`10Mbps;
`6 ms
`
`TFrn
`•••
`
`TFr0
`
`TCPrn
`•••
`
`TCPr0
`
`Figure 1: Simulation topology
`
`ms. The traffic from both sources are sharing this
`bottleneck bandwidth. The TCP flow is an FTP
`session and has unlimited data to send. Side links
`connecting to the bottleneck link have bandwidth
`of 10 Mbps with 6ms delay factor. The routers
`have a single output queue for each attached link,
`and initially uses RED scheduling discipline. The
`second round of
`the simulation
`uses Drop-
`Tail/FIFO scheduling as an alternative to RED.
`All simulations were run long enough until they
`achieved steady state behaviour. Table 2 sum-
`marises important simulation parameters used in
`these experiments.
`
`Parameter
`
`Default Value
`
`Packet size
`Bottleneck bandwidth
`Bottleneck delay
`Sidelink bandwidth
`ACK size
`TCP timer granularity
`Simulation length
`
`100 bytes
`1.5 Mbps
`20 ms
`10 Mbps
`40 bytes
`100 ms
`100 sec
`
`Table 2: Simulationparameters
`
`3.4 Simulation Parameters
`
`A fair comparison can only be achieved with care-
`ful selection of simulation parameters. We have
`used similar parameter values for all the flows
`wherever possible. The intermediate routers are
`connected by a bottleneck link with initial band-
`width set to 1.5 Mbps and initial link delay of 20
`
`4 Results of Experiments
`
`We have conducted a substantial number of
`experiments to evaluate the TCP-friendliness of
`the TF protocols.
`The following subsections
`present our results for these different experiments.
`
`6
`
`

`

`Average F
`
`2.31
`6.46
`8.64
`1.78
`4.79
`4.45
`
`Comment
`
`Unsatisfactory
`Very Poor
`Very Poor
`Unsatisfactory
`Very Poor
`Very Poor
`
`4.1 Router Policies
`RED)
`
`(FIFO versus
`
`4.1.1 Using DropTail/First-In-First Out (FI-
`FO) Router
`
`Experiment
`
`TFRC vs. Reno
`CG RAP vs. Reno
`FG RAP vs. Reno
`TFRC vs. Sack
`CG RAP vs. Sack
`FG RAP vs. Sack
`
`Table 3: Friendliness of TF flows coexisting with TCP
`withFIFOrouter
`
`sing number of flows, the TCP Reno obtain lesser
`bandwidth share in the case of CG RAP compared
`to that of in the case of TFRC in which 50 TCP
`Reno flows are still capable of securing about 1%
`of the bottleneck bandwidth. Thus, we can con-
`clude that TFRC is better protocol compared to
`RAP when coexisting with TCP Reno using FIFO
`router. This result is relevant to the situation at
`present where TCP Reno is predominantly used in
`the Internet [22].
`
`C
`
`G
`
`
`
`R
`
`A
`
`P
`
`
`
`v
`
`s
`
`
`
`R
`
`e
`
`n
`
`o
`
`
`
`w
`
`i
`
`t
`
`h
`
`F
`
`I
`
`F
`
`O
`
`TFRC
`
`v
`
`s
`
`.
`
`
`
`R
`
`e
`
`n
`
`o
`
`
`
`w
`
`i
`
`t
`
`h
`
`
`
`F
`
`I
`
`F
`
`O
`
`9
`
`8
`
`C R A P
`
`
`
`%
`
`8
`
`7
`
` %
`C
`R
`F
`T
`R
`e
`no %
`
`6
`
`5
`
`4
`
`3
`
`2
`
`1
`
`0
`
`BW Share (%)
`
`R
`
`e
`
`n
`
`o
`
`
`
`%
`
`2
`
`0
`
`4
`
`0
`
`6
`0
`l
` Flows
`
`T
`
`o
`
`t
`
`a
`
`8
`
`0
`
`1
`
`0
`
`0
`
`2
`
`0
`
`4
`
`0
`
`6
`0
`t
`a
`l
`
`T
`
`o
`
`
`
`F
`
`l
`
`o
`
`8
`0
`w
`s
`
`1
`
`0
`
`0
`
`7
`
`6
`
`5
`
`4
`
`3
`
`2
`
`1
`
`0
`
`BW Share (%)
`
`Figure 2: Bandwidth share of TF flows coexisting with
`TCPflowsusingFIFOrouter
`
`4.1.2 Using Random Early Detect
`Router
`
`(RED)
`
`In this set of experiments, we evaluate the perfor-
`mance of TF protocols versus various TCP Reno
`and Sack with RED as router policy. Table 4
`shows the results of these experiments.
`When using RED policy at intermediate routers,
`the TF protocols becomes more friendly towards
`competing TCP Reno flows. Note that the friend-
`liness index for TFRC is less than 1.00 indicating
`that the average throughput of TCP Reno flows is
`slightly higher than that of the TFRC. The high-
`er throughput can possibly result from the abili-
`ty of TCP Reno to acquire more bandwidth share.
`
`7
`
`In these set of experiments, we compare the per-
`formance of TF protocols when using FIFO po-
`licy at the intermediate routers. We believe that
`this comparison is important since FIFO is widely
`used and implemented in the routers [3]. Table 3
`presents the result.
`It is obvious from these results that TF protocols
`are considerably unfriendly in all the experiments
`using FIFO as routers. Nevertheless, TF proto-
`cols are more friendly with TCP Sack as compared
`to TCP Reno. TCP Sack obtains more bandwidth
`share in all the cases which therefore lead to high-
`er throughput. These result can be attributed to
`the feature of TCP Sack itself. In TCP Sack the
`receiving agents send back selective ACK packets
`to the sender informing the sender of data that has
`been received. The sender can then retransmit on-
`ly the missing data segments. As a result, a TCP
`Sack sender can obtain slightly more bandwidth
`for its flow. This is not the case with TCP Reno.
`With the normal type of acknowledgments, a TCP
`Reno sender can only know about a single lost
`packet per round trip time. This issue is impor-
`tant since RAP and TFRC both uses packet loss as
`an indicator for deciding their transmission rates.
`We also observed that the fine grain adaptation
`in RAP (FG RAP) does not facilitate the proto-
`col in obtaining more throughput when coexist-
`ing with TCP Reno. However when coexisting
`with Sack, the friendliness of FG RAP is slight-
`ly improved relatively indicating that TCP flows
`receive higher throughput. We can say that the
`use of feedback signal based on the ratio of the
`short-term exponential moving average of RTT to
`a long-term exponential moving average of RTT
`is useless when the coexisting TCP flow does not
`use selective ACK.
`Figure 2 illustrates CG RAP and TFRC per-
`formance in terms of bandwidth share when co-
`existing with Reno. Notice that with the increa-
`
`

`

`Average F
`
`0.77
`3.58
`3.92
`0.45
`3.95
`6.32
`
`Comment
`
`Satisfactory
`Poor
`Poor
`Unsatisfactory
`Poor
`Very Poor
`
`Experiment
`
`TFRC vs. Reno
`CG RAP vs. Reno
`FG RAP vs. Reno
`TFRC vs. Sack
`CG RAP vs. Sack
`FG RAP vs. Sack
`
`Table 4: Friendliness of TF flows coexisting with TCP
`withREDrouter
`
`sion rate to secure better bandwidth share. In the
`case of RAP versus TCP Sack, the performance
`of CG RAP is slightly better with RED. However,
`the use of RED causes FG RAP being unable to
`properly capture the short-term trends in conges-
`tion under heavy load. Consequently, FG RAP is
`not able to respond to the distress of TCP Sack,
`making it more aggressive in seizing bandwidth
`which leads to its higher throughput.
`
`Figure 3(a) supports our assumption. Figure 3(b)
`shows the bandwidth trace of one TFRC flow and
`one TCP Reno flow for a period of 100ms. It re-
`veals that the bottleneck bandwidth is fairly shared
`at around 50%. One possible explanation is that
`the ability of RED routers to absorb burstiness of
`TCP Reno making it more aggressive in obtaining
`the bandwidth. Also, The performance of RAP
`against TCP Reno is also improved when using
`RED routers even though the results are still con-
`siderably unfavourable.
`
`4.1.3 FIFO and RED Routers: Summary of
`Results
`
`In summary, performance of TFRC protocol is
`better compared to RAP regardless of the router
`policy implemented at the intermediate routers.
`However, the use of RED makes TFRC become
`more friendly. When using FIFO routers, RAP
`works better with TCP Sack compared to TCP
`Reno but still far unsurpassed compared to TFRC.
`Figure 4 presents overall results of TF protocol
`friendliness when coexisting with TCP Reno.
`
`TFRC
`Reno
`
`RAP and TFRC Friendliness
`
`FRAPvReno/FIFO
`TFRCvReno/FIFO
`CRAPvReno/FIFO
`CRAPvReno/RED
`FRAPvReno/RED
`TFRCvReno/RED
`
`14
`13
`12
`11
`10
`
`0123456789
`
`Friendliness Ratio
`
`0.00
`
`20.00
`
`40.00
`60.00
`Time (s)
`
`(b)
`
`80.00
`
`100.00
`
`2 0
`
`40
`
`6 0
`Total Flows
`
`8 0
`
`10 0
`
`80.00
`
`75.00
`
`70.00
`
`65.00
`
`60.00
`
`55.00
`
`50.00
`
`45.00
`
`40.00
`
`35.00
`
`30.00
`
`25.00
`
`20.00
`
`15.00
`
`10.00
`
`5.00
`
`0.00
`
`BW Share (%)
`
`TFRC vs. Reno with RED
`
`T F R C %
`
`R e no %
`
`2 0
`
`4
`
`0
`
`6
`
`0
`
`8
`
`0
`
`1
`
`0
`
`0
`
`T
`
`o ta l F lo w s
`
`(a)
`
`5 .5
`
`5
`
`4 .5
`
`4
`
`3 .5
`
`3
`
`2 .5
`
`2
`
`1
`
`.5
`
`1
`
`0
`
`.
`
`5
`
`0
`
`BW Share (%)
`
`Figure 3: Bandwidth share of TF flows coexisting with
`TCPflowsusingREDrouter
`
`Figure 4: Summary of TFprotocolfriendlinesswhen co-
`existingwithTCPReno
`
`The friendliness of the TF protocols is gene-
`rally better when coexisting with TCP Sack com-
`pared to that of with the TCP Reno, except for
`the case of FG RAP versus TCP Sack. The av-
`erage throughput of TFRC flows is slightly lower
`indicating that the TCP Sack flows are dominat-
`ing the bandwidth throughout the connection (at
`around 60%). This can possibly attributed to the
`aggressiveness of TCP Sack due to its abovemen-
`tioned retransmission feature as well as the ability
`of RED to absorb TCP burstiness. Due to this rea-
`son, TFRC senders cannot increase the transmis-
`
`We have so far seen that the TFRC and CG RAP
`coexisting with TCP Reno as the TCP friendliest
`among all the experiments. For the rest of this pa-
`per, we shall refer to CG RAP as RAP, TCP Reno
`as simply TCP otherwise explicitly stated. We al-
`so use RED as default router policy in the subse-
`quent experiments otherwise explicitly stated.
`
`4.2 Bottleneck Delay
`
`The effects of changing bottleneck delay on
`friendliness ratio of RAP and TFRC are clearly
`
`8
`
`

`

`shown in Table 5. The performance of TF proto-
`cols is not improved by decreasing bottleneck de-
`lay and indeed becoming worse. At the bottleneck
`delay of 20 milliseconds, the TFRC flows per-
`forms satisfactorily against its TCP counterpart.
`At the same delay, the RAP flow is also perfor-
`ming quite satisfactorily where both of their ave-
`rage throughput are higher than that of the TCP
`Reno. However, as the bottleneck delay is de-
`creased to 10 milliseconds, the average throughput
`for RAP flows increase more than 10% thus ma-
`king them more unfriendly with TCP Reno. TCP
`flows also become more aggressive and cause
`TFRC flows being unable to obtain a favourable
`bandwidth share. Hence TFRC flows obtain less
`average throughput compared to TCP.
`The situation can be simply explained. A smal-
`ler bottleneck delay indicates a smaller round-trip
`time. Both TCP and TF connections become more
`aggressive and achieve larger share of bandwidth
`with shorter RTT. It is also obvious that a TCP
`connection with shorter delay can update their
`window sizes faster than those with longer delays,
`thus capture higher bandwidth. This somehow af-
`fects the friendliness of the TF protocols.
`
`Experiment
`
`20 ms
`
`10 ms
`
`RAP
`TFRC
`
`1.84
`1.21
`
`2.88
`0.37
`
`Table 5: Effect of Reducing Bottleneck Delay on TCP-
`Friendliness
`
`4.3 Bottleneck Bandwidth
`
`The results of changing bottleneck bandwidth are
`displayed in Table 6. In this experiment, the bot-
`tleneck delay is kept constant. When the bot-
`tleneck bandwidth is doubled, the TF flows be-
`come more TCP friendly. At a smaller bandwidth,
`TCP losses become more dominant (as packets are
`dropped at the bottleneck router), thus caused TCP
`to deviate from the AIMD algorithm which in turn
`making TF flows getting bigger share of the band-
`width.
`
`With the increase in the bottleneck bandwidth,
`TCP flow becomes more stable and conforms to
`AIMD, possibly due to lesser losses (packet drops)
`at the router. Consequently, this makes TF flows
`become more adaptive and thus more TCP friend-
`ly. Again this behaviour is in agreement with the
`equation (1) with regard to the loss probability.
`
`Experiment
`
`1.5 Mbps
`
`3.0 Mbps
`
`RAP
`TFRC
`
`1.84
`1.21
`
`1.40
`1.13
`
`Table 6: Effect of Increasing Bottleneck Bandwidth on
`TCP-Friendliness
`
`4.4 Loss Rate
`
`In this set of experiments, we test the effect of in-
`creasing loss rate on the TF protocols. As men-
`tioned in Section 3.1, the use of equation (1) in
`controlling the sender’s rate guarantees that at loss
`rate of up to 5%, a rate-based control protocol
`using the equation will still be TCP-friendly. Ta-
`ble 7 shows the result of our simulation. The result
`clearly shows that RAP which does not explicitly
`use (1) to control its rate, begins to perform un-
`satisfactorily at loss rate increase of 5%. With the
`same increase, TFRC is still very TCP friendly.
`However, TFRC was unable to compete with the
`aggressiveness of TCP at loss rate higher than 5%.
`This situation has earlier been verified by simula-
`tions and clearly explained in [14].
`
`Experiment
`
`1% 5% 15%
`
`RAP
`TFRC
`
`1.28
`0.95
`
`1.79
`1.02
`
`4.58
`0.47
`
`Table 7: EffectofIncreasingLossRateonRAPandTFRC
`
`5 Conclusions
`
`In this paper, we have presented a performance
`comparison of two TF rate-base adaptation pro-
`tocols, namely RAP and TFRC. These protocols
`achieve friendliness by changing their sending rate
`
`9
`
`

`

`based on feedback signal from receiver. Our com-
`parison reveals that both protocols are able to
`achieve throughput that are close to the through-
`put of a TCP connection travelling over the same
`network path. However, our experimental results
`show that the equation-based TFRC protocol is
`more friendly and robust in most of our experi-
`ments, as compared to RAP.
`Our experimental results show that both pro-
`tocols perform better in the presence of RED as
`router. This is mainly due to the ability of RED
`router to evenly distribute losses across the flows
`and avoid buffer overflow over a wide range. We
`also demonstrate the effect of varying bottleneck
`delay and bottleneck link bandwidth on friendli-
`ness of TF protocols. The results also show that
`these protocols especially perform better at lower
`loss rate below 5%. Both protocols are no longer
`friendly at the rate higher than 5%.
`Our main goal for these experiments is to com-
`pare these two protocols and to find which is best
`rate-based protocol to support our future work in
`end-to-end quality of service support for strea-
`ming multimedia applications in the Internet. We
`have reached the verdict that the TFRC is the best
`between the two.
`
`6 Acknowledgements
`
`The authors wish t