corruption and reordering robust tcp-friendly rate control

Corruption and reordering robust TCP-friendly rate control

Rahul Chaudhary*, Lillykutty Jacob

Department of Computer Science, School of Computing, National University of Singapore, Lower Kent Ridge Road,

3 Science Drive2, Singapore, Singapore 117543

Received 19 June 2003; revised 22 April 2004; accepted 18 May 2004

Available online 11 June 2004

Abstract

TCP-Friendly Rate Control (TFRC) mechanism was introduced for regulated multimedia streaming over the Internet. TFRC unnecessarily

reduces the application sending rate in wired network scenarios with packet reordering. TFRC also gives poor performance over wireless

access networks. The poor performance of TFRC on paths that reorder packets and on wireless access networks can be attributed to its

inability to differentiate packet losses due to congestion from other network conditions like packet reordering and corruption. We first

examine the performance of TFRC over wireless network with UDP-lite that reduces packet drops over the wireless link. Next we propose

few methods to make TFRC robust in packet reordering scenarios and evaluate the performance of TFRC with these schemes incorporated.

Then we suggest a modification to TFRC from being loss-based to ECN-marking based. ECN-marking based TFRC performs rate regulation

according to actual network congestion experienced and is robust to packet reordering and corruption in the network. We provide the results

of our extensive experiments on a network testbed for various scenarios with packet corruption and/or packet reordering. We also observe the

impact of ECN-based TFRC on concurrent TCP flows.

q 2004 Elsevier B.V. All rights reserved.

Keywords: Wireless; TFRC; ECN; Reordering; UDP-lite

1. Introduction

Delay sensitive real-time multimedia streaming appli-

cations prefer using the connection-less UDP that does not

provide reliability, in-order delivery and congestion control

features like TCP. Using an unregulated transport protocol

for streaming is harmful for the health of the network as it

can cause an undesirable network situation called conges-

tion collapse [1]. For proper and efficient network

functioning, rate regulation of such uncontrolled streaming

is a must. Rate regulation for streaming applications using

UDP can be achieved through TCP-Friendly Rate Control

(TFRC) [2]. TFRC is an equation based congestion control

mechanism for unicast UDP flows which aims at providing a

smooth transition rate in the short time scale but in the larger

time scale consuming no more bandwidth than a TCP flow

under similar network conditions. It is a loss based rate

regulation mechanism, which controls the sending rate for a

UDP stream on the basis of packet losses that occur during

the transmission of the stream. This mechanism is devised

for wired networks where congestion is the only reason for

packet losses during transmission.

TFRC emulates a TCP-like transmission behavior and

thus treats reordered packets in a similar way as TCP does.

TCP congestion control requires the sender to wait for a

small number of duplicate ACKs (called reordering

threshold) to arrive before deciding whether a missing

packet is really lost [3]. TCP uses a reordering threshold of

three. Any packet that is reordered beyond this specified

reordering threshold value is treated as lost even if the

packet arrives later. For any network path that reorders

packets more than minimally the choice of three proves too

aggressive in concluding loss [4]. Zhang et al. [4] and

Blanton et al. [5] illustrate the impact of reordering on TCP

performance and propose several alternatives to dynami-

cally make TCP’s fast retransmission algorithm more

tolerant of the reordering. Measurement studies on packet

reordering over the Internet show that packet reordering is

not a rare event, 0.1–2.0% of packets experience reordering

over some paths, and the prevalence of reordering varies

across different network paths [6,7]. TFRC suffers from

packet reordering because it emulates TCP and treats

0140-3664/$ - see front matter q 2004 Elsevier B.V. All rights reserved.

doi:10.1016/j.comcom.2004.05.010

Computer Communications 28 (2005) 97–107

www.elsevier.com/locate/comcom

* Corresponding author. Tel.: þ65-945-20420; fax: þ65-687-26198.

E-mail addresses: [email protected] (R. Chaudhary),

[email protected] (L. Jacob).

http://www.elsevier.com/locate/comcom

a packet reordered beyond the threshold as lost packet.

Gharai et al. [8] discuss the effect of packet reordering on

the observed throughput of their TFRC flows over the

Internet. We propose several methods to make TFRC more

robust in the face of packet reordering.

Also, the inability of TFRC in differentiating congestion

losses from corruption losses attributes to poor TFRC

performance in wireless access networks where packet

losses can also occur due to error–prone wireless links. To

have a unified rate control mechanism for both wired and

wireless networks it is required that the mechanism

performs rate control only on the basis of actual congestion

situation experienced in the network and not be affected by

situations like packet reordering or packet corruption. We

hypothesize that making TFRC based on Explicit Conges-

tion Notification (ECN) [9] marking is a good solution for

efficient rate control in both situations of packet reordering

as well as packet corruption. ECN-marking based TFRC

performs sending rate control on the basis of actual network

congestion information that is provided by ECN marking

done in the packet headers by intermediate routers. The use

of ECN marking by routers that are based on active queue

management strategy like Random Early Detection (RED)

[10] is very common these days.

In this paper, we first measure the performance

improvement obtained through the combination of UDP-

lite, which reduces packet drops over the wireless link, and

TFRC. We then propose methods to make TFRC robust in

packet reordering situation. Instead of a loss being detected

by the arrival of three packets with higher sequence

numbers than the lost packet, the requirement for three

subsequent packets is made adaptive based on experienced

packet reordering. We also propose an ECN based TFRC

that accounts only congestion losses for sending rate

adjustment. It neither accounts the losses occurring over

the wireless hop nor the effect of packet reordering

encountered in the Internet. In this rate controlling scheme

intermediate routers detect incipient network congestion

and inform the multimedia sources using ECN marking,

which then calculate TCP friendly sending rate on the basis

of ECN-marking probability and not packet loss probability

as in TFRC.

We begin by providing some background on TFRC

mechanism, UDP-lite and ECN. In Section 3 we describe

several methods to make TFRC robust against packet

reordering. Section 4 describes our ECN based TCP-

Friendly Rate Control mechanism. Section 5 presents the

test setup used. Section 6 describes various test experiments

done by us, followed by the conclusion of our work in

Section 7.

2. Background

In this section we briefly discuss the various mechanisms

used in the paper

2.1. TCP-friendly rate control

TFRC is an equation based rate control mechanism for

unicast UDP flows. In order to compete fairly with TCP,

TFRC uses the TCP throughput equation to calculate its

sending rate. The TCP throughput equation roughly

describes TCP’s sending rate as a function of the loss

event rate, round-trip time, and packet size [2]:

X ¼s

R

ffiffiffiffiffiffi2bp

3

rþ RTO 3

ffiffiffiffiffiffi3bp

8

rpð1 þ 32p2Þ

" # ð1Þ

where X is the transmit rate, s is the packet size, R is the

round-trip time, p is the loss event rate of the number of loss

events as a fraction of the number of packets transmitted,

RTO is the TCP retransmission time out value, and b

is the number of packets acknowledged by a single ACK.

The TFRC protocol relies on the following steps:

† The receiver measures the loss event rate p and feeds this

information back to the sender.

† The sender receives these feedback messages and also

uses them to measure the round-trip time R:

† Next the loss event rate and RTT are fed by the sender

into the above throughput equation to compute the

acceptable transmit rate.

† The sender then adjusts its transmit rate to match the

calculated rate.

Calculating the loss event rate rather than simply taking

the packet loss rate is an important part of TFRC. TFRC

assumes that all packets contain a sequence number. The

receiver maintains a data structure that keeps track of which

packets have arrived and which are missing. The loss of a

packet is detected by the arrival of at least three packets with a

higher sequence number than the lost packet. The receiver

maps the packet loss history into a loss event record, where a

loss event is one or more packets lost in an RTT. This RTT is

supplied periodically by the sender. If the starting packet

sequence number of a loss event A is SA and the starting

packet sequence number of the next loss event is SB; then the

number of packets in loss interval A is given by ðSB 2 SAÞ:

Then the average loss interval Imean is calculated using a filter

that weights the n most recent loss event intervals. The loss

event rate, p is simply: p ¼ 1=Imean:

2.2. UDP-lite

UDP-lite is a modification to the classical UDP protocol

that can serve applications, which in a lossy network

environment prefer to have partially damaged packets

delivered rather than being dropped [11,12]. It provides

the sending application with a checksum that has an optional

partial coverage. Usage of this option causes a datagram to

be separated into a part sensitive to errors and a part

R. Chaudhary, L. Jacob / Computer Communications 28 (2005) 97–10798

insensitive to errors. The packet checksum covers only the

sensitive part leaving the insensitive part unchecked. Error

occurrences in the insensitive part don’t cause packet drop,

while errors in the sensitive part result in the packet being

dropped. The variable checksum coverage thus reduces

packet drops by not dropping packets that encounter errors

in the insensitive part of packet data. This partial

checksumming is provided by replacing the length field in

the classical UDP header with a checksum coverage field

that specifies number of bytes from the beginning of UDP

header, which are sensitive to error and are protected by

checksum. Detailed description of the protocol is available

in Ref. [12].

One fundamental problem is that link layer may drop

frames with errors before they reach the transport layer.

Larzon et al. [11] therefore suggest that the device driver at

the receiver be modified to ignore CRC errors for packets

carrying UDP-lite (real-time) traffic. The performance of

UDP-lite for video over cellular networks is evaluated in

Ref. [13]. It shows significant improvement over UDP in

terms of throughput and PSNR.

2.3. Explicit congestion notification

The Explicit Congestion Notification option [9] allows

active queue management mechanism such as RED to

probabilistically mark (rather than drop) packets when the

average queue length of the congested router lies between

two thresholds. The router sets the Congestion Experienced

(CE) bit in the packet header of packets from ECN-capable

transport protocols. For an ECN-capable TCP connection,

the receiver echoes back to the sender the fact that some of

its packets were marked, so the sender knows that the

network is approaching a congested state. The sender should

therefore reduce its congestion window as if the packet was

dropped. The sender should only react once per RTT to

congestion indications. The main advantages are that TCP

does not have to wait for a timeout and most packet drops

can be avoided.

3. Making TFRC robust against packet reordering

In Refs. [4] and [5] several methods have been proposed

to make TCP robust against packet reordering. We adopt a

few methods for making TFRC mechanism robust against

packet reordering. The reason for poor TFRC performance

in the face of packet reordering is its treatment of reordered

packets. TFRC maintains a threshold value, similar to TCP

dupthresh, of three for packets arriving out-of-order. Any

packet that arrives after three packets with sequence number

higher than it is treated as a lost packet. This behavior

causes problems for efficient TFRC performance in present

day networks where packet reordering is not a rare

phenomenon. For efficient TFRC performance in such

situations it is required to make the dupthresh flexible

and adjust it based on experienced packet reordering

conditions in the network.

3.1. Increase dupthresh by a constant K

In this method each time a reordering event occurs the

reordering threshold value dupthresh is increased by a fixed

constant value K; and the new dupthresh value is then used

for future reordering events. This means that whenever a

packet is missing the receiver waits for dupthresh packets

with higher sequence number to arrive. If the packet arrives

before dupthresh higher sequenced packets are received

then it is not treated as a lost packet. Otherwise a new loss

event is counted. The receiver, however, waits for the

missing packet to arrive and whenever this packet which has

been counted as lost but is actually reordered arrives, the

receiver increases the dupthresh by a constant K: Also, the

receiver does not wait infinitely for a missing packet to

arrive. It waits for a fixed time interval waiting-time that is

equal to an integral multiple of RTO, before finally

concluding that the packet is lost and restarting again with

a dupthresh of three.

The advantage of this method is its ease of implemen-

tation and its disadvantage is that the receiver may take long

to reach a dupthresh value which represents the actual

reordering situation being encountered in the network. The

actual performance of this method depends upon the value

chosen for constant K and the reordering encountered in

the network. This method is referred as TFRC-K in the

comparisons.

3.2. Adjust dupthresh to the average of reordering event

length L and current threshold dupthresh

In this method, at the occurrence of each reordering event

the dupthresh value is changed to the average of number of

higher sequenced packets after which the reordered packet

arrives (called length of reordering event LÞ and the current

dupthresh value. The initial value for dupthresh is three.

Whenever a reordering event occurs, which means that a

packet is missing in the sequence of packets received, the

receiver starts its wait for the missing packet and also starts

counting the number of higher sequenced packets that are

received before the missing packet is received. When the

missing packet arrives the receiver calculates L and updates

dupthresh to a new value which is the average of current

dupthresh and L:

The advantage of this method is that the receiver will

reach a dupthresh value that represents actual network

packet reordering condition faster as compared to the

previously suggested method of increasing dupthresh by

constant value K: A disadvantage of this mechanism is that

even a single abnormally long reordering event will increase

the dupthresh to a large value, which might in effect

cause the waiting receiver to exceed it waiting-time period.

Expiry of the waiting-time interval at the receiver can mean

R. Chaudhary, L. Jacob / Computer Communications 28 (2005) 97–107 99

that the packet was lost in the network and the current value

of reordering threshold might not be a correct estimate of

actual network packet reordering condition. To solve this

issue we use the same approach as in (A) above, i.e.

resetting the dupthresh to a value of three. In [5] also the

authors suggest resetting dupthresh to its original value

when a TCP retransmission timeout occurs. This method is

called TFRC-AVG in the comparisons.

3.3. Adjust dupthresh according to EWMA of reordering

event length

In this method, we keep an Exponentially Weighed

Moving Average (EWMA) of the length L of packet

reordering event. Whenever a packet is missing in the

sequence of received packets, the receiver waits for the

missing packet and starts counting the number of higher

sequenced packets received before the missing packet

arrive. This is similar to the previously suggested averaging

method, but in this case an exponentially weighted moving

average (EWMA) avg is maintained on the length of

reordering events L: Whenever a reordering event occurs the

EWMA is updated as follows:

if L . avg

avg ¼ ð1 2 aÞ:avg þ a:L

else

avg ¼ ð1 2 a:xÞ:avg þ ða:xÞ:L

where:

a is the EWMA gain and is typically kept as 1/3

x is the multiplicative factor and is typically kept as 4

After the new value of avg is computed the value for

dupthresh is updated to avg. Initially both dupthresh and

avg are set to three.

The advantage of this method is that dupthresh varies

according to actual network reordering conditions and an

abnormal reordering event can not expand it to a very large

value. For this method also if the receiver exceeds its

waiting-time value while waiting for the missing packet then

it resets dupthresh to three and starts afresh for a new

reordering event to occur. This method is called TFRC-

EWMA in the comparisons.

4. ECN-BASED TCP-friendly rate control

To make TFRC efficient for both wired and wireless

networks, we propose to make TFRC ECN-marking based

rather than being loss based. That is, instead of performing a

sending rate adjustment according to the loss event rate, the

TFRC mechanism should adjust the sending rate according

to the marking event rate. The receiver measures the

marking event rate based on the packets that arrive with

the ECN bit set, and feeds this information back to

the sender. This marking of ECN bit is done by RED

routers on the way from source to destination.

TCP throughput expression given by Eq. (1) is valid only

under the assumption that packets are dropped and has to be

modified in order to model a packet marking router. Since a

TCP flow experiences no loss when a packet is marked,

there are no timeout events and the throughput is the same as

the sending rate. This presumes that RED parameters are

also set such that average queue size is maintained within

RED thresholds. The TCP sending rate equation for the case

where there are no timeouts [14] is:

X ¼

s1 2 p

pþ

b þ 2

3bþ

ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffib þ 2

3b

� �2

þ8

3b

1 2 p

p

� �s24

35

Rb þ 2

6þ

ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffib þ 2

6

� �2

þ2b

3

1 2 p

p

� �sþ 1

24

35

ð2Þ

where the parameters have the same meaning as in Eq. (1)

except for p which is the marking event rate of the number

of marking events as a fraction of the number of packets

transmitted. Alternatively, we can also use the following

simple formula for the TCP sending rate [15] as it does not

account for timeouts:

X ¼1:3s

Rffiffip

p ð3Þ

where X is the transmit rate, s is the packet size, R is the

round-trip time, p is the marking event rate of the number of

marking events as a fraction of the number of packets

transmitted.

The ECN-based TFRC operates exactly the same way as

we described in Section 2.1 except for the fact that the

receiver now measures the marking event rate p and feeds

this information back to the sender. Packets get corrupted

over the wireless channel and are dropped. For the sake of

simplicity we assume that both ECN-marked packets and

unmarked packets suffer wireless loss with the same

probability so that the marking event rate p remains

unaffected as packets travel through the wireless channel.

Later, in our experiments, we find that this assumption

is valid.

Multimedia streaming over wireless access networks

using ECN-marking based TFRC is also proposed in

Ref. [16]. The authors argue that TFRC inherently being a

loss based rate control mechanism counts losses due to

packet corruption on the wireless link as congestion losses

and accounts them in its congestion control strategy. We

consider the ECN-based TFRC not only to mitigate the

impact of the wireless losses but also to mitigate the impact

of the packet reordering. Also, the authors of [16] use a

different TCP throughput equation for the TFRC sending

rate and their own proprietary implementation of the

TFRC, where as we use the available standard TFRC


implementation [17] which we modify to make it ECN-

capable as described above.

In the following sections, loss based TFRC will be

referred as just TFRC and marking based TFRC will be

referred as ECN-TFRC.

5. Experimental setup

We perform tests over a hybrid network testbed

comprising both wired portion and wireless last-hop. The

test setup used is shown in Fig. 1. The sending and receiving

hosts are all with FreeBSD 4.5 kernel and routers are also

running on FreeBSD 4.5. Bottleneck bandwidth and end-to-

end delay are set at router R2 using Dummynet [18]. To

simulate the wireless link packet corruption, we modify a

traffic shaping kernel module ‘rshaper’ [19] and install it on

router R4. This router selectively corrupts packets passing

through it according to a uniform distribution.

Reordering is done to selected flows using Dummynet

where randomly chosen packets are delayed for an extra

(specified) amount of time. The delay distribution for

reordering is chosen to be a normal distribution with

specified mean and standard deviation. We modify the

available TFRC implementation from loss based to ECN

marking based for our experiments. RED queue manage-

ment scheme in routers and ECN support in the intermediate

routers as well as at the end hosts are provided using ALTQ

[20] for FreeBSD.

6. Experimental results

We conduct several experiments: (a) to compare

performance of UDP-TFRC combination with UDP-lite-

TFRC combination; (b) to observe the improvements

attained through the use of various methods of dynamically

adapting dupthresh for TFRC; and (c) to compare

performance of TFRC and ECN-TFRC for flows encounter-

ing packet corruption, packet reordering and both packet

corruption as well as packet reordering. We repeat these

experiments for different network conditions. The results

presented in this paper are for a bottleneck bandwidth of

1.5 Mbps and end-to-end delay of 50 ms. Also we vary the

network congestion level by varying the number of

concurrent TCP/ECN-TCP and TFRC/ECN-TFRC flows.

6.1. TFRC flows encountering packet corruption:

comparison of UDP and UDP-lite

We perform experiments with three classes of flows: TCP

flows over wired end-to-end paths, TFRC flows over wired

end-to-end path and TFRC flows over path with wireless

last-hop. Packet corruption due to bit errors is introduced

over the wireless-hop. We perform two types of tests to

show reduction in the number of packets being dropped due

to corruption and resulting improvement in throughput: one

in which TFRC flows traversing the wireless-hop path use

UDP protocol and the other in which TFRC flows traversing

the wireless-hop path use the UDP-lite protocol. We do tests

with different degrees of packet corruption over the

wireless-hop and moderate network congestion level (i.e.

three flows each from the three classes of flows mentioned

above).

6.1.1. Using UDP as transport protocol

In these tests TFRC flows traversing the wireless last-hop

encounter packet corruption resulting in dropping of large

number of packets and thus have lower throughput when

compared to TFRC flows over wired end-to-end path (see

Fig. 2).

6.1.2. Using UDP-lite as transport protocol

For these tests also TFRC flows traversing the wireless

link encounter same level of packet corruption as the above

test, resulting in dropping of packets. However, the number

of packet drops is reduced because checksumming is done

only for the sensitive part of packet and packets, which have

errors in the insensitive part are not dropped. This causes

higher throughput for the wireless TFRC flows (see Fig. 3).

From Figs. 2 and 3 we can see that using UDP-lite

protocol in conjunction with TFRC results in better

throughput for the flows that traverse the wireless-hop.

Fig. 1. Testbed.

Fig. 2. Throughput of TFRC flows over wired/wireless path using UDP

(10% corruption).


But still the throughput for such a TFRC flow is lesser than

the throughput of a TFRC flow that traverses wired end-to-

end path.

Fig. 4 compares throughputs of TFRC flows traversing

wireless last-hop network path, using UDP and UDP-lite as

transport protocol, for different values of packet corruption.

For both the test cases we maintain a constant network

congestion level with three TCP flows, three TFRC flows

over the wired end-to-end path and three TFRC flows over

wireless last-hop path.

6.2. TFRC flows encountering packet reordering:

effect of different threshold adaptation methods

We conduct tests to compare the performance of different

dupthresh adaptation methods for TFRC flows encountering

packet reordering.

Fig. 5 shows throughputs for different dupthresh

adaptation schemes with varying levels of packet reordering

over the network path. From the figure we can observe that

all these methods for dynamically adapting the reordering

threshold perform better than the fixed dupthresh method.

Fig. 6 shows the occurrence of packet loss events for the

different methods. We notice that TFRC-K method incurs

more loss events before reaching a stable value for

dupthresh when compared to the TFRC-AVG method,

which approaches proper dupthresh value with lesser loss

events occurring. For the TFRC-EWMA method loss event

occurrence varies according to the pattern of reordering in

the network. TFRC-EWMA is not performing well because

the adaptation is sensitive to the choice of the parameters

a and x and also on the amount of reordering.

6.3. TFRC/ECN-TFRC flows encountering packet

corruption over wireless last-hop

We conduct tests to compare the throughputs of TFRC

and ECN-TFRC flows both encountering packet corruption.

For all the tests we use concurrent TCP/ECN-TCP flows,

normal TFRC/ECN-TFRC flows that do not encounter

packet corruption, and TFRC/ECN-TFRC flows that

encounter packet corruption.

6.3.1. Using TFRC mechanism

In these tests there are three classes of coexisting flows:

standard TCP flows (non-ECN capable), TFRC flows that

do not encounter packet corruption, and TFRC flows that

encounter packet corruption over wireless last-hop.

The TFRC flows which experience packet corruption

have lower throughput as compared to those TFRC flows

which do not experience packet corruption (see Fig. 7).

TFRC treats packet loss due to corruption also as congestion

loss and thus gives improper estimate of experienced

network congestion and lower throughput.

Fig. 3. Throughput of TFRC flows over wired/wireless path using UDP-lite

(10% corruption).

Fig. 4. Throughput comparison for TFRC flows over wireless path using

UDP and UDP Lite protocol.

Fig. 5. Throughputs for different dupthresh adaptation methods.

Fig. 6. Packet loss event occurrence for different dupthresh adaptation

methods.


6.3.2. Using ECN-TFRC mechanism

For these tests also there are three classes of flows

coexisting: ECN-capable TCP flows, ECN-TFRC flows that

do not encounter packet corruption and ECN-TFRC flows

that encounter packet corruption. The ECN-TFRC flows

that experience packet corruption have comparable through-

put to those which do not experience packet corruption (see

Fig. 8) because ECN-TFRC performs rate regulation only

on the basis of actual network congestion denoted by packet

marking probability and does not count corruption losses for

rate control. Notice that the corruption loss of the ECN

marked packets along with the non-marked packets slightly

reduces the throughput.

Fig. 9 shows throughput comparison for TFRC and ECN-

TFRC flows with different levels of packet corruption over

the wireless-hop.

Fig. 10 compares the normalized throughput of TFRC,

UDP-lite-TFRC (TFRC with UDP-lite) and ECN-TFRC

flows, for varying packet corruption levels, where through-

put of TFRC, UDP-lite-TFRC, and ECN-TFRC flows with

packet corruption is normalized with respect to the

corresponding throughputs without corruption. ECN-

TFRC flows give better performance than UDP-lite-TFRC

because though UDP-lite reduces the number of packets

being dropped due to corruption it does not eliminate packet

drops completely. These remaining packet losses are also

accounted as congestion losses by TFRC and thus it gives

lower throughput when compared to ECN-TFRC. From

Fig. 10 we observe that normalized throughput of ECN-

TFRC flow remains close to unity for all packet corruption

levels but normalized throughputs of TFRC as well as UDP-

lite-TFRC flows are always below unity.

Fig. 11 compares throughput of ECN-TFRC flows which

encounter packet corruption with throughput of ECN-TFRC

flows which do not encounter packet corruption, for

Fig. 7. Throughputs of TFRC flows with/without packet corruption

(5% corruption).

Fig. 8. Throughputs of ECN-TFRC flows with /without packet corruption

(5% corruption).

Fig. 9. Throughput comparison for wireless TFRC and ECN-TFRC flows,

with varying levels of packet corruption.

Fig. 10. Normalized throughput comparisons for TFRC, UDP-lite-TFRC,

and ECN-TFRC flows over wireless link.

Fig. 11. Throughput comparisons for ECN-TFRC flows over path

with/without packet corruption (5% corruption).


different network congestion levels but same level of packet

corruption. From the figure we can see that ECN-TFRC

flows that experience packet corruption have almost the

same throughput as ECN-TFRC flows that do not

experience packet corruption.

During the experiments we also observe the impact of

asymmetric path on TFRC performance. By asymmetric we

mean there are no packet losses in the forward direction;

however, feedback packets in the reverse direction experience

losses. Fig. 12(a) (resp. 12(b)) shows throughput comparison

of TFRC (resp. ECN-TFRC) flows over an asymmetric path

with TFRC (resp. ECN-TFRC) flows over normal path where

there are no losses in either direction. From the figure we can

observe that losses of even 10% feedback packets have almost

no effect on TFRC/ECN-TFRC performance.


reordering

We conduct tests to compare the throughput of TFRC flows

encountering packet reordering with the throughput of ECN-

TFRC flows encountering packet reordering. For all the tests

we use concurrent TCP/ECN-TCP flows, normal TFRC/ECN-

TFRC flows that do not encounter packet reordering and

TFRC/ECN-TFRC flows that encounter packet reordering.


In these tests there are three classes of flows coexisting:

standard TCP flows (non-ECN capable), TFRC flows that

do not encounter packet reordering and TFRC flows that

encounter packet reordering.

The TFRC flows that experience packet reordering have

lower throughput as compared to those TFRC flows which

do not experience packet reordering (see Fig. 13) because

TFRC treats packets reordered beyond the specified

threshold as lost packets and thus gives improper estimate

of experienced network congestion.


For these tests also there are three classes of flows

coexisting: ECN-capable TCP flows, ECN-TFRC flows that

do not encounter packet reordering and ECN-TFRC flows

that encounter packet reordering. The ECN-TFRC flows

that experience packet reordering have comparable through-

put to those which do not experience packet reordering

(see Fig. 14) because the estimate of packet marking event

rate is not affected by packet reordering.

Fig. 15 shows throughput comparison for TFRC and

ECN-TFRC flows with different levels of packet reordering.

We also include the plots for TFRC with the different

dupthresh adaptation schemes incorporated. ECN-TFRC

Fig. 12. (a) Throughputs of TFRC flows over normal/asymmetric path. (b) Throughputs of ECN-TFRC flows over normal/asymmetric path.

Fig. 14. Throughputs of ECN-TFRC flows with/without packet reordering

(10% reordering).

Fig. 13. Throughputs of TFRC flows with/without packet reordering

(10% reordering).


mechanism gives similar performance as TFRC-K and

TFRC-AVG mechanisms but better performance when

compared to TFRC-EWMA method.

Fig. 16 compares the normalized throughputs (defined

earlier in the context of Fig. 10) of TFRC and ECN-TFRC

flows for varying packet reordering levels.

Fig. 17 compares throughput of ECN-TFRC flows which

encounter packet reordering with throughput of ECN-TFRC

flows which do not encounter packet reordering, for

different network congestion levels but same level of packet

reordering. From the figure we can see that an ECN-TFRC

flow that experiences packet reordering has almost the same

throughput as an ECN-TFRC flow that does not experience

packet reordering.


reordering over wired portion and packet corruption

over wireless hop

We conduct tests for both TFRC and ECN-TFRC

mechanisms. The flows traversing the hybrid path encounter

Fig. 16. Normalized throughput comparisons for TFRC and ECN-TFRC

flows, over path encountering reordering.

Fig. 17. Throughput comparison of ECN-TFRC flows over path with/

without packet reordering (5% reordering).

Fig. 15. Throughput comparison for TFRC and ECN-TFRC flows, with

varying levels of packet reordering.

Fig. 18. Throughputs of TFRC flows over wired/hybrid path (5% corruption,

5% reordering).

Fig. 20. Normalized throughput comparisons for TFRC and ECN-TFRC

flows over hybrid path (5% corruption, 5% reordering).

Fig. 19. Throughputs of ECN-TFRC flows over wired/hybrid paths

(5% corruption, 5% reordering).


packet reordering over the wired portion and packet

corruption over the wireless hop. The flows along the

wired path also encounter same packet reordering condition.


For these tests there are three classes of traffic coexisting:

standard (non-ECN capable) TCP flows over wired path,

TFRC flows over wired path, and TFRC flows over hybrid

(wired-wireless) path. All the flows encounter packet

reordering over the wired portion. The TFRC flows on

the hybrid path also experience packet corruption over the

wireless last-hop. They have lower throughput compared to

end-to-end wired TFRC flows due to the packet corruption

over the wireless-hop (see Fig. 18).


For these tests also we have similar coexisting traffic as

in Section 6.5.1 but the standard TCP flows are replaced by

ECN-capable TCP flows and the TFRC flows are replaced

by ECN-TFRC flows. All the flows encounter same packet

reordering over the wired portion as in the previous TFRC

test. Also the flows over the hybrid path encounter same

packet corruption condition over the wireless-hop. How-

ever, in these tests the ECN-TFRC flows over hybrid path

have throughput comparable with that of ECN-TFRC flows

over the wired path (see Fig. 19).

We also observe that ECN-TFRC flows over the hybrid

path have higher throughput compared to the TFRC flows

over the hybrid path under similar network conditions.

Fig. 20 shows the normalized (defined earlier in the context

of Fig. 10) throughputs of TFRC flows and ECN-TFRC

flows traversing hybrid network path, for different network

congestion levels. Fig. 20 shows that normalized throughput

of ECN-TFRC flows remains close to unity even with

the occurrence of both packet reordering and packet

corruption whereas for TFRC flows it is well below unity

under the same network conditions.

Fig. 21 shows throughput comparison for ECN-TFRC

flows over wired and hybrid paths with varying levels of

network congestion. The marking event rate estimate is not

affected by the wireless losses due to packet corruption, thus

the ECN-TFRC flows over hybrid path have throughput

comparable to ECN-TFRC flows over wired path for all

congestion levels.

6.6. Other observations

During the tests we measure the average queue size at the

intermediate router to ensure that no packet drops occur

when ECN-TFRC is used. In other words, we ensure that the

average queue size is maintained within the minimum and

maximum queue size thresholds so that there are only

marking and no dropping of packets. Fig. 22 below shows

the average router queue size for a test using three ECN-

TCP, three wired ECN-TFRC and three ECN-TFRC flows

on hybrid path, with packet reordering occurring over

the wired portion and packet corruption occurring over the

wireless-hop. The average queue size is well within the

minimum and maximum thresholds of the RED router.

An important observation regarding the use of ECN-

TFRC in conjunction with concurrent ECN-TCP versus the

use of TFRC in conjunction with concurrent normal TCP is

that both ECN-TFRC and ECN-TCP flows perform better

Fig. 21. Throughput comparison for ECN-TFRC flows over wired/hybrid

path (5% corruption, 5% reordering).

Fig. 22. Average router queue size.


than normal TFRC and TCP flows. When several TCP and

TFRC flows traverse a congested bottleneck link a large

number of packets are dropped at the congested router. The

loss based TFRC mechanism adjusts its sending rate

according to this situation however TCP suffers under

such highly loaded conditions as it frequently experiences

timeouts due to large number of packet drops at the

congested router. When ECN-TFRC and ECN-TCP are

used then because no packets are dropped at the intermedi-

ate router and thus no timeout events occur for the ECN-

TCP flows, they perform better and attain higher through-

puts than normal TCP flows. Fig. 23 shows the throughput

comparisons of TCP and ECN-TCP flows, which have

concurrently running TFRC and ECN-TFRC flows resp., for

increasing network congestion levels. We can observe that

the throughput of a TCP flow is always lower than

the throughput of an ECN-TCP flow, under similar network

congestion conditions.

7. Conclusion

Loss based TFRC has low throughput in wireless

network scenarios due to packet corruption. Loss based

TFRC also gives degraded performance over wired

networks where packet reordering is encountered because

it treats packets reordered beyond a particular threshold as

lost packets. We show the effect of UDP-lite in reducing the

impact of packet corruption on TFRC performance. Then

we suggest three methods for dynamically adapting

dupthresh and show that these schemes make TFRC robust

to packet reordering in the wired network. Next we

hypothesize that ECN marking based TFRC can perform

better than loss based TFRC for multimedia streaming

applications which encounter packet reordering in the

Internet and also when they traverse wireless hops. We

measure the improvement provided by ECN-TFRC over

TFRC for flows traversing wireless last-hop with packet

corruption, for flows traversing wired end-to-end with

packet reordering and for flows traversing hybrid network

path, encountering packet reordering as well as wireless-hop

packet corruption. In all the cases when TFRC mechanism is

used the flows lag behind flows which use ECN-TFRC.

Moreover, ECN-TFRC flows over hybrid path have

comparable throughput with ECN-TFRC flows over wired

path. We also notice the impact of ECN-TFRC on

concurrently flowing ECN-TCP flows and observe that

using ECN-TFRC makes ECN-TCP flows perform better

than TCP flows that are used along with TFRC.

References

[1] S. Floyd, K. Fall, Promoting the use of end-to-end congestion control

in the internet, IEEE/ACM Trans. Networking 7 (4) (1999) 458–472.

[2] M. Handley, J. Padhey, S. Floyd, J. Widmer, Rate control (TFRC):

protocol specification, RFC 3448 (2003).

[3] M. Allman, V. Paxson, W. Stevens, TCP congestion control, RFC

2581 (1999).

[4] [.4.].M. Zhang, B. Karp, S. Floyd, RR-TCP: A Reordering-Robust

TCP with DSACK, ICSI Technical Report TR-02-006, Berkeley, CA,

July (2002).

[5] E. Blanton, M. Allman, On making TCP more robust to packet

reordering, ACM Comput. Commun. Rev. 32 (1) (2002).

[6] J.C.R. Bennett, C. Partridge, N. Shectman, Packet reordering is not

pathological network behavior, IEEE/ACM Trans. Networking 7 (6)

(1999) 789–798.

[7] V. Paxson, End-to-end internet packet dynamics, IEEE/ACM Trans.

Networking 7 (3) (1999) 277–292.

[8] L. Gharai, C. Perkins, Implementing congestion control in the real

world, IEEE Int. Conf. Multimedia Exp. 1 (2002) 397–400.

[9] K.K. Ramakrishnan, S. Floyd, A. Proposal, A proposal to add explicit

congestion notification (ECN) to IP, RFC 2481 (1999).

[10] S. Floyd, V. Jacobson, Random early detection gateways for congestion

avoidance, IEEE/ACM Trans. Networking 1 (4) (1993) 397–413.

[11] L-A. Larzon, M. Degermark, S. Pink, UDP-lite for real-time

multimedia applications, In Proceedings of Sixth IEEE International

Workshop on Mobile Multimedia Communications, Nov, 1999.

[12] L-A Larzon, M. Degermark, S. Pink, G. Fairhurst, The UDP lite

protocol, ,draft-ietf-tsvwg-udp-lite-01.txt . .

[13] A. Singh, A. Konrad, A.D. Joseph, Performance evaluation of udp lite

for cellular video, NOSSDAV 01, pp: 117–124, Jun. 2001.

[14] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, Modeling TCP

throughput: a simple model and its empirical validation, Proceedings

of ACM SIGCOMM 98, vol. 28, 1998, pp. 303–314.

[15] J. Mahdavi, S. Floyd, TCP-Friendly unicast rate-based flow control,

End-to-end Interest Mailing List, Jan.1997.

[16] S. jun Bae, S. Chong, TCP-friendly wireless multimedia flow control

using ECN Marking, IEEE GLOBECOM, vol. 2, 2002, pp. 1794–1799.

[17] Implementation of TCP-friendly congestion control protocol (TFRC),

available at: http://www.icir.org/tfrc/code/

[18] L. Rizzo, Dummynet: a simple approach to the evaluation of network

protocols, ACM Comput. Commun. Rev. (1997).

[19] Alessandro Rubini, Rshaper: Module for traffic shaping, available at:

http://www.linux.it/rubini/software/rshaper.

[20] ALTQ: alternate queuing for BSD UNIX, available at: http://www.csl.

sony.co.jp/person/kjc/kjc/software.htmlALTQ

Fig. 23. Throughputs for TCP/ECN-TCP flows.


http://www.icir.org/tfrc/code/

http://www.linux.it/rubini/software/rshaper

http://www.csl.sony.co.jp/person/kjc/kjc/software.htmlALTQ

http://www.csl.sony.co.jp/person/kjc/kjc/software.htmlALTQ

corruption and reordering robust tcp-friendly rate control

Documents