CONGESTION CONTROL ACROSS A VIDEO-DOMINATED

INTERNET TIGHT LINK

E. A. Jammeh, M. Fleury and M. Ghanbari

University of Essex, ESE Dept.

Wivenhoe Park, Colchester CO4 3SQ, U.K.

Keywords:

Congestion control, video streaming, fuzzy logic.

Abstract:

Existing congestion controllers have been designed with TCP trafﬁc in mind. Changing trafﬁc patterns on

the Internet imply that on some tight links all UDP video streams will occur. Three different congestion

controllers (RAP, TFRC, and fuzzy-logic based), already successful in avoiding instability in current TCP-

dominated internets, were tested across a tight link in which video trafﬁc dominated. Congestion control is

either achieved by modulating the sending rate in response to feedback of packet loss rates and/or round-trip

delays (RAP/TFRC) or a congestion level based on packet dispersion across a network path (fuzzy controller).

The controllers were found to differ in the smoothness of resulting video clip streams, with the fuzzy and

TFRC controllers, in that order, producing the smoothest received video. Tests also demonstrated that, when

controlled ﬂows of different types compete across a tight link, it is possible for the sending rate of TFRC to

exceed the available bandwidth, resulting in excess packet loss and implying quite poor video quality at the

receiver. The results show that fuzzy-logic control is more ﬂexible when video streams dominate.

1 INTRODUCTION

The Internet’s growth has encouraged multimedia ap-

plications, such as real-time delivery of sports and

news clips, and the exchange of pre-encoded per-

sonal video clips (peer-to-peer streaming). If some

Internet links are dominated by video clip streams

and/or DVD-video streaming, how will congestion

controllers cope with this situation? Currently, TCP-

based applications dominate the Internet. TCP’s fu-

sion of error and congestion control coupled with its

ﬂuctuating sending rate make it suitable for data traf-

ﬁc transport and unsuitable for unicast multimedia

streams. TCP-friendly Rate Control (TFRC), now

an RFC (Handley et al., 2003a), is representative of

equation-based control, mimicking TCP’s Additive

Increase Multiplicative Decrease (AIMD) congestion

probing algorithm. However, in (Cai et al., 2005), it

is remarked that ”It is unclear whether the model it-

self still applies when the mix of TCP and non-TCP

trafﬁc changes dramatically over time as new applica-

tions keep emerging over the Internet”.

The Rate Adaptation Protocol (RAP) (Rejaie et al.,

1999) is a well-known alternative to equation-based

modeling, varying the inter-packet gap (IPG) between

UDP packets at the sender, to allow its average send-

ing rate to approach TCP’s for a given available band-

width. Equally, fuzzy logic-based congestion control

has been shown (Jammeh et al., 2005) to closely track

capacity over a tight link, especially when there are

a limited number of ﬂows, as feedback if over the

same link may lead to a non-linear control system.

Fuzzy-logic control avoids the need to directly uti-

lize packet loss (Jammeh et al., 2006) as an input to

the congestion controller, as packet dispersion on the

Internet path forms the feedback. Therefore, when

rate-controlled transcoding (Assunc¸

ao and Ghanbari,

1998) is employed, the video rate can be modulated,

resulting in low loss rates, which are clearly beneﬁcial

to video quality.

All three methods (TFRC, RAP, fuzzy) may avoid

network instability in current trafﬁc scenarios but how

might they react in a situation in which all trafﬁc over

a particular congested link is controlled by means of

the same scheme, which we call intra-protocol fair-

ness or all trafﬁc consists of congestion-controlled

UDP streams, which we call inter-protocol fairness?

This seems to be a question that has not received suf-

ﬁcient attention in the research literature.

A 2003 survey (Fraleigh et al., 2003), reporting on

A. Jammeh E., Fleury M. and Ghanbari M. (2006).

CONGESTION CONTROL ACROSS A VIDEO-DOMINATED INTERNET TIGHT LINK.

In Proceedings of the International Conference on Signal Processing and Multimedia Applications, pages 89-94

DOI: 10.5220/0001567700890094

 SciTePress

trafﬁc samples taken in 2001-2, indicated that me-

dia streaming and distributed ﬁle sharing trafﬁc had

risen to 60% of the total in the ’Sprint’ network core,

with only 30% contributed by Web trafﬁc. The report

found considerably variety in the trafﬁc mix, depend-

ing on link type and link capacity. Peer-to-peer ﬁle

sharing trafﬁc had a strong impact but up to 26% of

any sampled link’s trafﬁc was formed by streaming

applications. This mix might lead to still higher link

concentrations, once passing from the network core to

the network edge.

Network congestion impacts the delivery of en-

coded video due to an inconsistent and constrained

available network bandwidth, increase in one-way

delay and jitter, with an increased packet loss rate.

Over-provisioning is unlikely to remove this prob-

lem (Gevros et al., 2001), because of bandwidth mis-

matches at the Internet’s periphery. Therefore, the

key problem is reacting to congestion caused by other

trafﬁc as the stream passes across such a bottleneck.

It is also worth noting that RealVideo, which may

account for over 40% of commercially streamed mul-

timedia content, has been shown with a network test-

bed (Chun et al., 2002) to be particularly unfriendly

to equivalent TCP ﬂows, with 20% of UDP ﬂow ac-

quiring in the long run as much as twice the rate of a

TCP ﬂow during network bandwidth constriction (for

a constriction of 300 kb/s and below, fed from a 700

kb/s DSL link to the Internet). This remains a prob-

lem that congestion controllers restrained by the TCP

throughput equation are badly placed to meet.

The remainder of this paper is organized as follows.

Section 2 introduces the three congestion controllers

that are compared. Section 3 describes the experimen-

tal methodology. Section 4’s results consider two key

problems: 1) delivery of a smoothly varying video

stream; and 2) avoiding packet loss from too aggres-

sive bandwidth acquisition takes place. Finally, Sec-

tion 5 draws some conclusions.

2 CONGESTION CONTROLLERS

2.1 Tfrc Control

In TFRC, (Handley et al., 2003b), the sending rate

is made a function of the measured packet loss rate

during a single round-trip time (RTT) duration mea-

sured at the receiver. The sender then calculates the

sending rate according to the TCP throughput equa-

tion reported in (Padhye et al., 1998). Therefore,

TFRC is restricted to situations in which the TCP

throughput equation is applicable. TFRC was de-

signed to produce smooth multimedia ﬂows but, be-

cause it assumes constant-sized large (MTU) packet

sizes, it introduces a bias against the variable-sized

packets of variable bit-rate (VBR) video. TFRC’s

throughput model is sensitive to the loss probability

and RTT, which are difﬁcult to predict or measure.

Ironically, TFRC may perform better when there are

packet losses, but this is not conducive to the qual-

ity of delivered video. Another potential weakness is

the response to short-term TCP ﬂows, typically HTTP

trafﬁc, which never develop long-term TCP ﬂow be-

havior.

2.2 Rap Control

RAP (Rejaie et al., 1999) uses acknowledgment pack-

ets (ACKs) to detect packet loss and infer RTTs.

Every smoothed RTT, RAP implements an AIMD-

like algorithm with the same thresholds and incre-

ments as TCP. Because this would otherwise result

in TCP’s ’sawtooth’-like rate curve, with obvious dis-

ruption to video streams, RAP introduces ﬁne-grained

smoothing (turned-on in Section 4’s tests), which

takes into account short- and long-term RTT trends

(by forming the ratio of the two). As time-outs for

single loss detection are not applied, RAP’s output

is greater than equivalent TCP trafﬁc during heavy

congestion. RAP’s form of rate control also implies

ﬁxed-size packets, again creating problems for VBR

video.

2.3 Fuzzy Control

Fuzzy congestion control is a sender-based system

for unicast ﬂows across the Internet, principally ap-

plied to rate-controlled transcoded video. Transcoded

video allows the rate to dynamically adapt to chang-

ing network conditions as well as match the capabili-

ties of a variety of receiver devices.

The main constituents of the fuzzy logic conges-

tion controller are a fuzzy inference system, a rule

base and a defuzziﬁer. The fuzzy inference system

uses a Mamdani model (Mamdani and Assilian, 1975)

with two inputs: 1) congestion level 2) instantaneous

rate of congestion level change. The video receiver

device returns a feedback message indicating the dis-

persion of packet inter-arrival times from which the

sender then calculates time-smoothed changes to the

congestion level. A fuzzy inference system maps the

given inputs to an output using fuzzy-logic member-

ship functions to ‘fuzzify’ the input. The mapping is

performed by means of ’if-then’ rules and fuzzy op-

erators.

Subsequently, centroid of area defuzziﬁcation is

applied to arrive at a crisp output level. The sender

then modulates the sending rate according to this out-

put level, in practice by applying a control signal to a

transcoder’s quantization level. The result is a stream

of variable-length packets with a ﬁxed IPG. The dis-

persion of the IPGs is recorded ar the receiver.

SIGMAP 2006 - INTERNATIONAL CONFERENCE ON SIGNAL PROCESSING AND MULTIMEDIA

APPLICATIONS

This is a ﬂexible method of control, suitable for

variable-bit rate (VBR) video, that can control output

(Jammeh et al., 2006) in the presence of short- and

long-term HTTP ﬂows.

3 TEST METHODOLOGY

To ensure fairness to both RAP and TFRC

publicly-available ns-2 models (in the form

of object tcl scripts to drive the sim-

ulator) was availed of respectively from

http://netweb.usc.edu/reza/RAP/NewRAP/

and http://www.icir.org/tfrc/, with the fuzzy

models available from this paper’s ﬁrst author.

In both RAP and TFRC, the constant packet length

was set in the supplied scripts to 1000 B. The max-

imum packet size in the fuzzy tests was also set

to 1000 B but the fuzzy controller alters the packet

length to achieve a desired bitrate. The fuzzy sys-

tem IPG (the time between the end of transmission

of one packet and the start of another) was set to 2.2

ms, which is equivalent to an MPEG-2 video stream

at 25 frame/s for European SIF-sized pictures with

18 slice/frame and one slice in each packet. How-

ever, the source was Constant Bit-Rate(CBR) and not

a VBR video emulation or trace, so as to avoid invali-

dating the comparison with TFRC and RAP. IPG dis-

persion information is fed back after every frame or

frame transmission interval (every 40 ms in the simu-

lation) from the receiver. Again a ﬂexibility of fuzzy-

control is that feedback does not need to be so often

as in AIMD-based control. For fuzzy-controlled VBR

trafﬁc refer to (Jammeh et al., 2006).

The RAP model assumes that rate transitions are

quantized (as in layered coding), though the source

utilized in the simulation does not emulate or make

use of video traces. Unlike, RAP, the fuzzy con-

troller in practice (not simulation) is integrated with

a transcoder and, thus, could readily achieve ﬁne-

grained adaptation. TFRC’s simulation model source

is not video-speciﬁc but simply provides packets up

to the available rate, though a smoothing option was

turned on. Decision frequency is every RTT. In all

simulations, packets were always available at source.

In order to calibrate the models, the ability to track

a varying available bandwidth was tested. Fig. 1

shows that both fuzzy and RAP control are able to fol-

low scheduled changes by the simulator. The transi-

tions made by the controllers are abrupt, though not as

abrupt as the limited resolution of the graphs may sug-

gest. The main difference is in the smoothness of the

response, as RAP’s response was notably less smooth,

whereas TFRC’s response (not shown) is similar to

the fuzzy controller. From (Girod, 1992) and else-

0.5

1.5

2.5

0 50 100 150 200 250 300

Sending Rate (Mbit/s)

Time (seconds)

Fuzzy Rate

Available Bandwidth

(a) Fuzzy control response

0.5

1.5

2.5

0 50 100 150 200 250 300

Rate (Mbit/s)

Time (seconds)

Rap

Available Bandwidth

(b) RAP control response

Figure 1: Tracking available bandwidth stepped over time.

where, abrupt changes in received video quality are

known to having a disturbing effect on the viewer.

The main determinant of RAP’s behavior, as decision

frequency is similar to TFRC, appears to be the size

of (stepped) rate transitions, which coarsens the tran-

sition levels available despite ’ﬁne-grain smoothing’.

Fig. 1 as with others in this study shows sending rate

and not router response. This implies that when the

sending rate is above the available bandwidth there

will be packet loss, though smoothing in intermedi-

ate router buffers may reduce the effect. However, in

the case of Fig. 1 a ﬁxed reduction in rate, a safety

margin, should result in the fuzzy controlled stream

avoiding loss.

In live tests of 4000 video clips (Chun et al., 2002),

over 50% of clips were less than 200 s with a median

of 180 s, which is similar to the experiments in Sec-

tion 4. The same experiment found that the median

packet length with UDP streaming was 640 B, which

is similar to the ﬁxed packet length of RAP and TFRC

in the tests. By means of transcoding or layered cod-

ing, a VCR quality or even MPEG-2 broadcast video

rate can be gracefully degraded to around 1 Mb/s,

CONGESTION CONTROL ACROSS A VIDEO-DOMINATED INTERNET TIGHT LINK

while in the U.K. peak ADSL bandwidth at house-

hold access links remains at 2.9 Mb/s, which explains

the choice of rates and bottlenecks in the following

Section.

4 RESULTS

In the intra-protocol fairness experiments, a number

of CBR streams were simultaneously transmitted over

a shared tight link, representing the minimum avail-

able bandwidth on an end-to-end path. In the ns-2

simulator, this arrangement was modeled by a ’dumb-

bell’ topology. Five simultaneous ﬂows were pre-

sented; other tests for up to ten simultaneous ﬂows re-

vealed similar results. No TCP trafﬁc was present but

a set of identical TCP-friendly controllers competed

for available bandwidth. The simulator was unable to

set the feedback at exactly the same time for all the

controllers and, therefore, as for Internet sources, the

output was not identical even though the congestion

controllers were.

Fig. 2 shows the intra-protocol allocation of band-

width for the three congestion controllers for a sam-

ple 2.0 Mb/s bottleneck over a 120 s period (time for

a video clip to be exchanged). The average bandwidth

of any one ﬂow for each sampled bandwidth remains

close to the required value, as the fuzzy example,

Fig. 3, illustrates. Very similar plots occur for RAP

and TFRC congestion controllers and at different bot-

tleneck settings. Therefore, clearly all three conges-

tion controllers appear ’friendly’ to themselves.

Though all ﬂows, for each type of controller, clus-

ter around the correct level, Fig. 2, given the avail-

able bandwidth, RAP is visibly more ’bursty’ in its

response. The RAP plot shows a large initial send-

ing rate, which was discarded in subsequent analysis

to avoid biasing the comparisons by this start-up fea-

ture. The issue is less easy to resolve between TFRC

and the fuzzy controller and to do so the Coefﬁcient

of Variation (CoV) was taken for the aggregated set

of ﬁve ﬂows. The CoV is calculated for any one bot-

tleneck bandwidth by taking the mean and standard

deviation (s.d.) of each ﬂow over the 120 s period and

then forming the mean of the means and the mean of

the s.d.s. The aggregate s.d.s are then normalized by

the aggregate means to form the CoV for each data

point.

Fig. 4 plots the CoV response across a range of bot-

tleneck bandwidths in which TFRC exhibits more ex-

cursions than fuzzy control. To conﬁrm that fuzzy is

less bursty than TFRC, Table 1 tabulates the s.d.s for

a sample of two ﬂows (the other ﬂows were similar)

taken at random from the ﬁve for each of the con-

gestion controllers. In each case, the fuzzy controller

s.d.s are consistently less than those of TFRC (and

RAP), showing that in these circumstances the fuzzy

controller’s output is smoother.

Table 1: S.D.s for a sample two ﬂows over 120 s tests.

Congestion Bottleneck Flow1 Flow2

controller b/w (Mb/s) s.d. (Mb/s) s.d (Mb/s)

TFRC 2.0 0.448486 0.63709

RAP 2.0 1.35377 0.97761

Fuzzy 2.0 0.27979 0.28815

TFRC 5.0 1.483344 1.47669

RAP 5.0 2.80038 2.13319

Fuzzy 5.0 1.38128 1.53012

Turning to inter-protocol allocation of bandwidth,

Fig. 5 shows two ﬂows with different congestion con-

trollers illustrating that both behave reasonably to

each other, with similar bandwidth allocations and

with dominance oscillating between each controller.

However, this impression is dispelled when mul-

tiple ﬂows compete, Fig. 6, when the average band-

width of the TFRC ﬂows are always above that of the

fuzzy-controlled ﬂows and above an ideal or equally-

shared bottleneck bandwidth. Clearly, if replicated

in a network this behavior would result in increased

packet loss for the TFRC ﬂows. We postulate that the

cause of this behavior is over-sensitivity on the part of

TFRC to variation in packet loss and RTT. One impli-

cation is that TFRC may closely model TCP’s average

throughput but doing so may result in untoward loss

of quality for received video.

5 CONCLUSIONS

A number of conformant congestion controllers (ones

that are TCP-friendly) have been developed. Tests

now show that, three of these at least (RAP, TFRC

and fuzzy) are largely equivalent in their response to

trafﬁc ﬂows from the same type of congestion con-

troller (either all RAP or TFRC or fuzzy). How-

ever, RAP controller’s stepped response to feedback

does not result in smooth ﬂows. Smoother ﬂows

allow graceful degradation of transmitted video in

the face of congestion and smaller receiver buffers.

The end result may translate into a better subjective

experience by the user viewing the received video

and reduce the problem of buffering memory on mo-

bile devices. There is also a reduced risk of packet

loss at router queues. Because it does not employ

AIMD’s bandwidth probing and through design of

its membership models, fuzzy control is favored over

TFRC in that respect. TFRC assumed more than an

equal share of available bandwidth in inter-protocol

tests (when trafﬁc from other congestion controllers

SIGMAP 2006 - INTERNATIONAL CONFERENCE ON SIGNAL PROCESSING AND MULTIMEDIA

APPLICATIONS

was present), which in practice would lead to greater

packet loss. Feedback of packet inter-arrival time dis-

persion, rather than packet loss or two-way delay, may

help the fuzzy controller to keep its sending rate to the

available bandwidth, leading to higher quality video

at the receiver.

REFERENCES

Assunc¸

ao, P. and Ghanbari, M. (1998). Bit rate control

of Internetworking video transcoders. In Fifth Inter-

national Conference on Electronics,Circuits, and Sys-

tems, ICECS’98, volume 2, pages 247–250.

Cai, L., Shen, X., Pan, J., and Mark, J. W. (2005). Perfor-

mance analysis of TCP-friendly AIMD algorithms for

multimedia applications. IEEE Transactions on Mul-

timedia, 7(2):339–335.

Chun, J., Zhu, Y., and Claypool, M. (2002). FairPlayer

or FoulPlayer? —head to head performance of Re-

alPlayer streaming video over UDP versus TCP. Tech-

nical report, Worcester Polytechnic Institution, MA.

Fraleigh, C., Moon, S., Lyles, B., Cotton, C., Khan, M.,

Moll, D., Rockell, R., Seely, T., and Diot, C. (2003).

Packet-level trafﬁc measurements from the Sprint IP

backbone. IEEE Network, 17(6):6–17.

Gevros, P., Crowcroft, J., and Bhatti, S. (2001). Congestion

control mechanisms and the best effort service model.

IEEE Network, 15(3):16–26.

Girod, B. (1992). Psychovisual aspects of image communi-

cation. Signal Processing, 28(3):239–251.

Handley, M., Floyd, S., Padyhe, J., and Widmer, J. (2003a).

TCP friendly rate control (TFRC): Protocol speciﬁca-

tion. IETF RFC 3448.

Handley, M., Floyd, S., Padyhe, J., and Widmer, J. (2003b).

TCP friendly rate control (TFRC): Protocol speciﬁca-

tion. RFC 3448.

Jammeh, E., Fleury, M., and Ghanbari, M. (2005). A TCP-

friendly fuzzy congestion controller for transcoded

video over the Internet. In International Symposium

on Telecommunications, Shiraz, Iran, Sept.

Jammeh, E. A., Fleury, M., and Ghanbari, M. (2006). Non-

packet-loss-based rate adaptive video over the Inter-

net. Electronic Letters, 42(8):492–494.

Mamdani, E. H. and Assilian, H. (1975). An experiment in

linguistic synthesis with a fuzzy logic control. Inter-

national Journal of Man-Machine Studies, 7(1):1–13.

Padhye, J., Firoiu, V., Towsley, D., and Krusoe, J. (1998).

Modeling TCP throughput: A simple model and its

empirical validation. In ACM SIGCOMM ’98, pages

303–314.

Rejaie, R., Handley, M., and Estrin, D. (1999). RAP: An

end-to-end rate-based congestion control mechanism

for realtime streams in the Internet. In IEEE INFO-

COM’99, volume 3, pages 1337–1345.

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0 20 40 60 80 100 120

Rate (Mbit/s)

Time (seconds)

(a) RAP

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0 20 40 60 80 100 120

Rate (Mbit/s)

Time (seconds)

(b) TFRC

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0 20 40 60 80 100 120

Rate (Mbit/s)

Time (seconds)

Figure 2: Five simultaneous ﬂows each with identical con-

gestion controllers for a 2 Mb/s bottleneck.

CONGESTION CONTROL ACROSS A VIDEO-DOMINATED INTERNET TIGHT LINK

0.2

0.4

0.6

0.8

1.2

1.4

1.6

1.8

2.2

2 3 4 5 6 7 8 9 10

Rate (Mbit/s)

Bottleneck Bandwidth (Mbit/s)

Flow1

Flow2

Flow3

Flow4

Flow5

Figure 3: Average bitrate for each of ﬁve ﬂows over a range

of bottlenecks.

0.05

0.1

0.15

0.2

0.25

0.3

2 2.5 3 3.5 4 4.5 5

CoV

Bottleneck Bandwidth (Mbit/s)

TFRC

FUZZY

RAP

Figure 4: Mean CoVs of ﬁve ﬂows for a range of bandwidth

bottlenecks.

0.5

1.5

2.5

3.5

0 20 40 60 80 100 120

Rate (Mbit/s)

Time (seconds)

Fuzzy

TFRC

Figure 5: Competing ﬂows with Fuzzy/TFRC over a 3.0

Mb/s bottleneck.

0.2

0.4

0.6

0.8

1.2

1.4

2 2.5 3 3.5 4 4.5 5 5.5 6

Average Sending Rate (Mbit/s)

Bottleneck Bandwidth (Mbit/s)

F 1

F 2

F 3

T 1

T 2

IDEAL

(a) 3 Fuzzy 2 TFRC

0.2

0.4

0.6

0.8

1.2

2 2.5 3 3.5 4 4.5 5 5.5 6

Average Sending Rate (Mbit/s)

Bottleneck Bandwidth (Mbit/s)

F 1

F 2

F 3

T 1

T 2

T 3

IDEAL

(b) 3 Fuzzy 3 TFRC

Figure 6: Competing ﬂows with different controllers across

a range of bottlenecks.

SIGMAP 2006 - INTERNATIONAL CONFERENCE ON SIGNAL PROCESSING AND MULTIMEDIA

APPLICATIONS