Link Estimation and Rate Control for OptimizedVideo Streaming on Overlay Networks

Nguyen Huu Thanhl, Ngo Quynh Thu2 , Nguyen Tai Hung''Faculty of Electronics and Telecommunications

2 Faculty of Information TechnologyHanoi University of Technology

Hanoi, VietnamEmail: thahhm1:huLed v, , 2th

Abstract- A set of applications such as IP-TV, Internet videobroadcasting, corporate telecast or E-learning requiresimultaneous transmission of video streaming over the Internet.However, conventional solutions for Internet streaming serviceshave exhibited several disadvantages such as server overload andcongestion in the immediate network nodes, especially in case oflarge number of clients. These solutions are also failed to provideQoS-guarantees for streaming services across a heterogeneousinternet. In this article, we propose a novel overlay architecturethat is designed for multimedia streaming transmission on theInternet. Basic facility for overlay multicast has been introduced,which can relay a single content to multiple users withconsideration of bandwidth available on the overlay links. Also,we deploy a link estimation algorithm to analyze the overlay linkcondition, which is exposed to congestion and interference. Basedon the link estimation algorithm, we developed a rate adaptationalgorithm to adapt the transmission rate to the downstreamavailable bandwidth. Our real implementation shows that thenew proposed algorithms greatly improve the perceived qualityof service at the client, while better utilize network resources.

Keywords: video streaming; pear-to-peer; overlay networks;rate control; bandwidth estimation; multicst distribution tree

I. INTRODUCTION

A set of applications such as IP-TV, Internet videobroadcasting, corporate telecast or E-learning requiresimultaneous transmission of video streaming over the Internet.Conventional solutions for Internet streaming services haveexhibited several disadvantages. Firstly, due to the nature ofvideo applications, streaming services generally require largebandwidth for its transmission. Moreover, the client-servermodel, in which many clients connect directly to the server toretrieve the streaming contents, requires much larger aggregatetransmission bandwidth as well as computing power at theserver. This can lead to server overload and congestion in theimmediate nodes of the network. Secondly, such value-addedservices as IP-based video streaming are increasingly deployed,specially in wireless network environment (e.g., WLAN andUMTS). However, the recent Internet infrastructure, which haslimited service functionality and is still mostly best-effort inbackbone, cannot accommodate increasing demand of users onstreaming services with reasonable quality. This task is evenmore difficult if the number of users is large and if they arelocated in a wide area network with various accesstechnologies and have different available bandwidth.

Thus, in order to accommodate new demand on multimediastreaming services, new network architectures and mechanismshave to be provisioned to satisfy the following requirements:(1) utilize network resources efficiently in terms of bandwidth,storage, computing power etc. and (2) scaleable in a networkwith large number of clients across heterogeneous networkenvironments.

In this article, we propose a novel overlay architecture thatis suitable for multimedia streaming, especially for videoservices on the Internet. By building an overlay network on topof the Internet, such additional mechanisms as QoS-guarantees,application-layer multicast, bandwidth estimation and ratecontrol etc. can be provisioned to improve the perceivedquality at receivers and effectively utilize network resources,while the underlying IP network remains unchanged.

Our approach has several contributions:

* In order to support the transmission of video streamingservices in heterogeneous environments includingfixed and wireless networks, we develop a novel linkestimation mechanism. The new mechanism measuresthe current loss rate of the data traffic and categorizesthe lost packets into two classes: (1) loss due tocongestion; and (2) loss due to interference on thewireless link. It also estimates the available bandwidthof the downstream overlay link for optimizedtransmission of streaming media.

* Based on the measurement results, we propose a rateadaptation and control algorithm that minimizes thebad effect of a bottlenecked link on the perceivedquality at the client site, while avoiding congestion tobe worsened. The mechanism is suitable forvideo/audio streaming media, especially for the newH.264 video coding standard.

* Although such mechanisms as bandwidth and linkestimation, rate adaptation and congestion control havebeen studied in the research community [16,17], wefound that until now there is only few works thatprovide integrated QoS mechanisms for multimediastreaming on the overlay. Our platform is a realimplementation. It applies multiple mechanisms thatenable to facilitate more reliable and efficient overlay

1-4244-0569-6/06/$20.00 t2006 IEEE 58

communication for multimedia streams and to optimizeutilization of available bandwidth.

* Additional mechanisms like forwarding errorcorrection in case of low quality at the wireless link orpacket scheduling to support QoS [10] are alsoprovided in the solution, although this article focuseson the link estimation and rate control issues.

The rest of this article is organized as follows. Section IIgives an overview on current approaches for video streamingand discusses specific issues when providing streamingservices on the overlay. Section III describes our architecturefor overlay multimedia streaming as well as its designobjectives. In Section IV, we introduce our link estimationalgorithm, which is capable of estimating the overlay linkcharacteristics in terms of available bandwidth and loss ratedue to interference in wireless environments. In the section wealso describe the rate adaptation algorithm that can improve theperceived quality of video services at the user side, whileutilizes network bandwidth more efficiently. The test scenarioand the results are shown in Section V, proving the advantagesof the new overlay architecture. Last, Section VI discusses theremained issues and future directions.

II. STREAMING ON THE OVERLAY -ISSUES ANDCHALLENGES

A. Current Aproaches for Video Streaming in the Internet

Coneto an overloa

_Data flo IP node 1Dat flow E1 IP node

IP link 0 End user IP linke 0 End user

Figure 1. (a) Client- Server model for video streaming (left); (b) IPmulticast model (right)

Streaming services are understood as services that areconsumed (heard, read, viewed) while being delivered oversuch IP-based networks as the Internet. While multimediastreaming services can be the delivery of audio (such asMPEG3) or video contents (e.g., MPEG2, MPEG4, H.264 etc.)over the Internet, in this article we mostly focus on the videostreaming services as these services have posed more complexproblems. This is because of their bursty nature and largebandwidth consumption [1,2]. As mentioned earlier, the client-server approaches (Figure la) for video streaming services cancause server overload and congestion in the immediate nodeson the network. One can think of IP layer multicast as asolution for the problem [3,4,5]. In IP multicasting, any hostwishing to receive shared data is required to join into thecorresponding multicast group. Upon receiving an IP packet, amulticast-capable router replicates the packets to all interfaceshaving multicast hosts (Figure lb). IP multicast is the mostefficient way to perform group data distribution, as it is able toreduce packet replication on the wide-area network to the

minimum necessary. Unfortunately, multicast routing is stillnot widely deployable in IP backbone because multicastrouting protocols are fairly complex and do not scale very wellin large networks [6]. Moreover, although much research hasbeen conducted on the area of QoS multicast routing protocols[7-9], it appears to be difficult to accommodate multiple QoSrequirements of users participating in the same multicast group.Other issues such as congestion control, pricing etc. inmulticast scenarios also contribute to the complexity ofimplementation.

A

D

1.

I

I

D,

Figure 2. Overlay model: (a) Underlying network topology in the overlaysceniario; (b) Logical overlay multicast tree

Another solution of the above mentioned issues is theoverlay approach. In an overlay network, the virtual overlaytopology is established based on overlay nodes connectedtogether by overlay links. Overlay nodes are normally end-hosts that have additional logic to perform application-layerfunctionalities like application-layer multicasting, searchservices, resource sharing or application-layer congestioncontrol, while underlying nodes is this paper is referred to asnodes at the network layer, which are only capable of layer-3routing and forwarding. An overlay node can have somefunctionalities of the underlying node but not vise versa (Figure2). Similarly, underlying links are referred to as IP links thatconnect underlying nodes. In contradiction, overlay links arethe logical connection between overlay nodes. Each overlaylink can consist of several IP links (Figure 2a). The overlaylinks can be created dynamically to establish the overlaymulticast tree (Figure 2b). In the context of multimediastreaming on the overlay, the root of the overlay multicast treeis called root node, the upstream node (e.g., node B in Figure2b) and the downstream node (e.g., node C) in an overlay linkare calledparent node and child node, respectively. A node canbe the client relative to its parent node and at the same time bethe server relative to its child node.

Overlay networks have several advantages in comparison toconventional approaches:

* By building the overlay network, the underlyingfunctionalities are hidden from higher layer. Thusoverlay nodes need only connectivity from theunderlying networks to build additional overlayfunctionalities (QoS-guarantee, multicast etc.), whilethe underlying IP network remains unchanged.

* By moving the functionalities from the core(immediate nodes) to the edge of the network (end-nodes), the overlay solution is more scaleable as itreduces complexity exhibited in the previousapproaches. This attractive feature can be explained asthe followings: (1) There is no need to allocate a global

1-4244 0569-6/06/$20.00 u2006 IEEE

group identifier, such as an IP multicast address thusminimizing complexity in the overlay system; (2)Since data is sent via unicast, flow control, congestioncontrol, and reliable delivery services that are availablefor unicast can be exploited.

Besides advantages, the overlay network architecture alsohas some drawbacks. Firstly, since data is forwarded betweenend-systems, end-to-end latencies can be high. Moreover, untilnow overlay network is used mostly for such elasticapplications as computer cycle or file sharing [18,19].Transmitting video traffic on the overlay poses some specificchallenges, which will be described in Section JIIB.

B. Streaming on the Overlay- General Problem DescriptionConsidering the quality-of-service (QoS) requirements for

streaming media applications, such as playback continuity,delay constraint, and large bandwidth consumption, thefollowing issues are critical for media streaming service thatneed to be addressed.

1) Application-layer multicastfor video streaming.-In IP multicast, the multicast tree is established based on

the immediate routers in the network, which are always online.In contradiction, the overlay nodes in an overlay multicastscenario are end-hosts, which can freely join or leave theoverlay multicast group at any time. The consequence is thatthe overlay multicast tree is very dynamic and unreliable. Thatis, each time a client joints or leaves a group, the overlaytopology changes accordingly. For elastic applications like filesharing, the change in topology does not have a remarkableaffect on the services. However, streaming applications requiretheir data to be delivered in a timely manner. Thus, dynamicityin the overlay is one serious issue to be solved. There arerecently several works on the area of reliable application-layermulticast for multimedia streaming. In general, the works onthe area can be categorized into two directions: (1) single- treemulticast with proxy caching [13,14]; and (2) multiple-treemulticast with path diversity [ 1,12].

2) Heterogeneity in network environments.,

Scalability is one major design principle of an overlaynetwork. That is, the overlay should accommodate a largenumber of users residing in different types of access networks,from fixed broadband Gigabit Ethernet to wireless LAN andUMTS. These networks show different link characteristics interms of capacity, link latency as well as packet error rate.

More technically, the issue of network heterogeneity can bemodeled in Figure 3. Let us consider an overlay hopconnecting two overlay nodes A and B in the multicast tree.The dashed line describes the virtual overlay link i, whichspans over N underlying nodes and (N -1) underlying links.Since the underlying IP links locate in various networkingenvironments, the overlay link can experience loss orerroneous packets caused by several reasons.

* Loss due to congestion: since the underlying links areshared by many end-to-end flows, buffer overflow inthe immediate routers can occur when the incomingrate at a node is larger than its serving rate (Figure 3).

Loss due to interference: wireless links in theunderlying networks have most complex andunpredicted behavior since the underlying linkcharacteristics change dynamically and depend verymuch on the environment. The impact of channelinterference on signal is defined by the Signal-to-NoiseRatio (SNR) and Bit Error Rate (BER). At the receiver,corrupted and unrecoverable incoming packets aredropped by the layer 2 or layer 3 functionalities (Figure3).

* Erroneous packets due to interference: it is noted thatmany link- and network-layer protocols supportForwarding Error Correction (FEC), which has theability to recover a limited number of bit errors in apacket. However in most cases, only bits in the headerfields are protected. That means the payload deliveredto an overlay node could still be erroneous and will bediscarded by the end-system.

A fixed

1 2

congestion

wireless

nterference

--~Overlay link

IP link

B

Ci3 cil-I

congestion

IP node

Overlay node

Figure 3. Overlay link includes several underlying links with differentcharacteristics

Thus, from the overlay perspective, packet loss and packeterrors can occutr somewhere on the overlay link between twooverlay nodes. In many cases, this will severely degrade thequality of services, since streaming media, especially layeredvideo traffic, is sensitive to packet loss. MPEG-2, 4 or H.264 Iframes are more sensitive to loss since they are normally largerthan B and P frames and have to be transported over severalRTP packets. One lost packet in the frame leads to the discardof the whole frame.

In order to minimize the negative impact of packet loss anderror, the parent and child nodes (i.e., node A and B in Figure3) have to take some cooperative actions. In case of networkcongestion, reducing the sending rate of active flows helpsminimize the bad effect on network performance. In contrast,loss due to interference cannot be avoided by rate reduction. Infact, such method as FEC is more appropriate in this case.Thus, in order to take an appropriate action on packet loss, theoverlay node is required to differentiate loss that is due tocongestion and loss due to interference. Unfortunately, the lossdifferentiation issue is fairly complex because of the followingreasons: (1) since packet loss occurs at the link layer ornetwork layer, an overlay node experiences packet loss as awhole; and (2) since the overlay node (at the edge of thenetwork) and the underlying nodes (at the core network) residein different locations and the overlay node can hardly have anyknowledge about the underlying immediate nodes, suchapproach as cross-layer to obtain information on lower link

1-4244 0569-6/06/$20.00 u2006 IEEE 660

quality and capacity is not applicable. In this article, loss dueto congestion is referred to as congestion loss; and loss due tointerference is referred to as interference loss.

3) Heterogeneity in QoS and service requirements.In an overlay multicast scenario, not only network

environment but also the client's end-system areheterogeneous. For instance, a high resolution desktop wouldrequire higher video transmission rate for a better resolution incomparison to a PDA with a smaller display, although theyretrieve the same content.

Thus, multicasting for clients with heterogeneous QoSrequires that a node in the multicast tree adapt the sending rateto each client it serves. It is also essential that the joiningprocedure takes the QoS requirements into account to optimizethe overlay multicast topology.

III. OVERLAY ARCHITECTURE FOR MUTLTIMEDIASTREAMING

A. Design Objectives

TABLE I. PROTOCOLS AND CODING SCHEMES SUPPORTED BY THEOVERLAY ARCHITECTURE

Signalling

Multimedia transmission

Quality feedback

Supported audio/video coding schemes

RTSP

RTP

RTCP-RR, -SR, -APP

MPEG 2, 3, 4;H.264/AVC

The design objectives of our overlay architecture are tosolve some of the above mentioned issues (see Section ILB).These objectives are the followings:

* Fully conformant with the Internet Streaming MediaAlliance (ISMA) standards in order to be compatiblewith current video-on-demand servers and players.

* Transparent to clients: the overlay functionalitiesshould be hidden from the user.

* Support graceful degradation of service in case ofcongestion and interference.

* Efficient utilization ofnetwork resources.

Our overlay network is based on a set of overlay nodes;each node consists of a multimedia gateway that relays themultimedia data to the next hop(s) and an RTSP signalingproxy that is responsible for multicast signaling and controllingthe multimedia gateway. Both multimedia gateway and RTSPsignaling proxy are fully software-based and are developed inLinux. Table I shows the standards supported by our overlayarchitecture. An overlay node supports standard multimediaprotocols as well as several audio/video coding schemes, thus itis fully compatible with existing audio/video servercomponents (such as QuickTime or DarwinStreamingServer)and players (MS Media Player, QuickTime etc.) Thearchitecture presented here is based on the Open MultimediaStreaming Architecture in [10].

B. Features

1) Application-Layer Multicast

R oin(R) R1 2

1 2Rediect2?) 1 2 ( 3 4

Redire Xt.(4) OK

) etbb; Xb tin(4)

Figure 4. Joining the overlay multicast tree

In the new architecture, when a new client wants to joininto the multicast tree (Client 5 in Figure 4), it dynamicallyregisters itself with the server (the root node in the multicasttree) by using RTSP messages. The root node makes a localdecision based on its knowledge of the overlay topology anddelegates this node to its direct child located in the next hop.This process repeats until the new client reaches its nearestserving node, which might also be another client that joins thetree sometime before. Until now, the issue of topologydynamicity has not been solved yet. In this article, we willfocus on our Link Estimation and Rate Control algorithms.

2) Per-Hop RTCP FeedbackOne remarkable feature of the new overlay architecture is

that it makes use ofper-hop RTCP-RR feedback instead of theconventional end-to-end solution. It is worthy to note that in amulticast scenario, it makes little sense if every end-user sendsRTCP-RR feedback to the server, since the server cannotaccommodate to each user's quality. Thus we deploy anotherconcept, where every immediate overlay node senses its uplinkquality (in terms of available rate and loss rate) and sends themeasured data to its upstream node. The upstream node derivesthe information from the RTCP-RR message, deploys suitablemethods to improve quality of the media, but does not forwardthe original message on the upstream. It in turn evaluates thequality of its uplink and sends its own message to its parentnode.

IV. LINK ESTIMATION AND RATE CONTROL ALGORITHMS

This section describes the link estimation and rate controlalgorithms in the overlay architecture. As mentioned in theprevious section, one essential overlay functionality in supportof QoS-guarantee is the link estimation mechanism. Linkestimation perform the following tasks: (1) to differentiate andestimate the congestion loss and interference loss; and (2) toestimate the available bandwidth of the downstream link.Firstly, we introduce the concept of the work and then wedescribe the link estimation and rate control algorithms.

A. ConceptWe have developed the link estimation and rate adaptation

mechanisms based on per-hop RTCP receiver report (RTCP-RR) [15]. Our concept is especially suitable for videostreaming applications. When congestion occurs in a link, thedownstream node of the link will detects loss rate based on thepacket rate it receives. Then it sends an RTCP-RR to its parentnode, reports how many packets are lost. The parent node, in

1-4244 0569-6/06/$20.00 u2006 IEEE 661

turn, tries reactively to drop less essential part of the video data(i.e., P and B frames) ahead of the more important ones (Iframes).

Li-n LiLn r

-----I Congeston irTetUrnce

4IJ}t) g

4I (t)Loss flow

1~,-FM --i

7)__

1dZ,Co

- Overlay link

Figure 5. Link model

In our architecture, an overlay node can carry severalstreaming sessions (e.g., for video and audio at the same time).Each session is identified by the Synchronization Source(SSRC) in the RTP header. Figure 5 shows the loss modelbetween two overlay nodes. Consider a sessionj, we denote:

* Ni and Ni+1 - two overlay nodes connected by theoverlay link Li .

* I7(t) and /lII (t) - the total number of cumulative lostpackets of session j in all upstream overlay linksobserved by node Ni and Ni+ , from the start ofsessionj until time t.

* li J (t) - the cumulative lost packets of session j at Liuntil time t.

* dJ (t) and d7J+ (t) - the number of cumulativedropped packets performed by the rate controlalgorithm of session j at Ni and Ni+1 until time t,respectively.

Note that lJ(t) , 4i (t) and di (t) are monotonousincreasing functions with time. We have the followingequation:

1jjl(t)= liJ (t)+diJ(t) +1J (t) (1)

or the number of cumulative lost packets at link Li can becalculated as following:

I i (t iJ+(t- dij (t Ij(t (2)

It is noted that consecutive packets in a streaming RTPsession must have consecutive and increasing sequencenumbers, which are stored in the RTP header. Thus themeasurement module in N1+1 can easily calculate l7j+ (t) if itnotices some missing sequence numbers from the arrivingpacket stream. The node N1+1 then sends the values of l7/+ (t)for every active session j periodically back to its upstream

node N1 via RTCP-RR messages. lji (t) is stored in the 24-bitcumulative number of packets lost field in the RTCP-RRmessage. di7(t) and l71jl(t) can also be derived by themeasurement module in Ni at any point of time. Thus, Ni can

calculate the number of cumulative lost packets 4i i (t) at Liuntil time t based on Equation (2). Now that we have to

estimate the number of lost packets 4] (t - a, t) at Li in a timeinterval [t - a, t]

Ii (t - aSt) = liJ(t) - 1iJ(t - ) (3)

Here T denotes the time interval between two consecutiveRTCP-RR messages. From Equation (2) and (3), at time t thenumber of lost packets in the interval [t - a, t] can be estimatedas:

4i(t - r, t) = I (t) - d7 (t) - / J(t) - i J (t ) (4)

B. Link EstimationThe rate estimation algorithm is activated periodically, each

time the node receives an RTCP-RR feedback from its childnode. The algorithm firstly estimates the loss rate of thedownlink according to Equation (6). Let t* be the time point inwhich congestion occurs, s/ (t - a, t) be the number of

departure packets and a/j (t - a, t) be the available bit rate forsessionj at Ni in the interval [t - r, t] . Node Ni estimates theavailable bandwidth as the following:

* If liJ (t - r, t) = 0: (before t )

(5)Si (t-T,t)

* If li I (t - a, t) #O: (after t )

(6)aij (t - a, t) = aij (t - 2T, t - a) - t ( ' );

The meaning of Equation (6) is that if lost rate of a sessionduring the last RTCP-RR time interval is larger than zero, thanthe estimated available rate for the next period should bereduced by that number of lost packets divided by the timeperiod , and the initialized available rate (before congestionoccurs) is calculated according to Equation (5). Also, Equation(6) implies that firstly the system considers 4ii (t - a, t) as lossdue to congestion. In the algorithm, if the gateway remarks thatthe loss ratio after rate reduction remains the same, it does notperform this operation in the next period. That means:

* If l (t -r,t) .0 and liJ (t -r,t) >1i i (t -2r,t -r)

a'(t -r,t) = a(t -3r,t-2T) (7)

1-4244 0569-6/06/$20.00 u2006 IEEE 662

Calculate a/j (t - a, t); /*Eq..(7)*/

ii, (t) = (1 - w) x i (t -a) +w x i'(t -a, t) (9)

The term ij (t - a, t) in Equation (8) is the interference loss

rate in the period [t -, t] . From ij(t -r, t) , the average

interference loss iij (t) until time t can be calculated by usingthe Exponential Window Moving Average (EWMA) withparameter 0 < w < 1.0 (Equation (9)).

If congestion does not exist anymore then the gateway triesto increase the rate of each session by F .ai (t - , t) , where0 < Fin, < 1.0 is a pre-defined increasing factor. Following isthe rate estimation algorithm, which is activated upon receivingthe RTCP-RR message.

As can bee seen, the outputs of the algorithm are theavailable bitrate and the interference loss rate. Whileinformation on available bitrate is needed in the Rate ControlAlgorithm, interference loss can be used for an adaptive FECon the overlay. Previous work on FEC has been mentioned in[10]. The Link Estimation Algorithm is described as follows:

Initialize a/ (t - a, t); /*according to Eq. (5)*1

Calculate li J (t - a, t) ; /*according to Eq. (4)*/

If lJ(t -,t)= Oand aJ(t -,t)> s/( 't)

aj (t - a, t) aj (t - 2r, t - ); /*no congestion*/

congestion false;

Else if l(t -r, t) = Oand a/(t - r, t) <s( 't)

aij (t - a, t) = aij (t - 2T, t - a)

+ Finc .a (t - 2r, t - a); /*recovery from conges.*/

congestion= false;

Else /* iJ (t -T,t). O /

If congestion=false /*begin the conges. period*/

congestion=true

If li y(t-,r,t) < ijj(t-2T,t-T)/*congestion avoidance*/

Calculate a (t - r, t);

/*according to Eq.(6)*/

Else /* lJ(t -r, t) > i i (t - 2r,t -r) *1

/*calculate the available bw and interefence loss*/

Calculate i/ (t - a, t) ; /*Eq.(8)*/

Calculate iiJ (t); /* Eq.(9)*

C. Rate Control AlgorithmThe task of the rate control algorithm is to adapt the

sending rate to the available bandwidth. In case of congestion,it reduces the sending rates to avoid congestion exaggeratingwhile keeping the perceived quality of the received streams asacceptable as possible. If congestion no longer exists, itgradually increases rates to take advantage of the full linkcapacity. It is noted that the H.264 standard puts the packetpriority information in the RTP-extended header, so thatpackets belonging to an I, P or B video frame can berecognized without reconstructing the whole video frame at theimmediate node.

Our algorithm makes use of a new concept that is calledmulti-threshold traffic shaper. Using multi-threshold trafficshaper at the output allows more important packets to "borrow"bandwidth from other packets, so that less important packetscan be dropped instead of the important ones. Furthermore, weuse frame discarding instead of packet discarding, i.e., if apacket is discarded, other packets belonging to the impairedvideo frame are also discarded. This can save bandwidth forpackets of other intact frames. The recognition of packets in aframe is based on the Time Stamp header field in the RTPheader.

The multi-threshold traffic shaper is based on the tokenbucket filter algorithm. It is used to police and shape trafficpattern at the output of a network node. The token bucket filterattempts to upper-bound the output traffic of a connectionj in atime interval by the average rate and maximum burst size,which correspond to the token rate Ri and the token bucket

depth B,. In the new multi-threshold traffic shaper, multipletoken bucket depths are used. Each threshold in our multi-threshold traffic shaper is used for an individual packetpriority. Particularly, we use three thresholds for I, P and Bvideo packets. The multi-threshold traffic shaper follows thebelow rules:

* Tokens fill up the bucket with the rate Rj (in packet/s)

* The bucket can hold at most Bi tokens (in packets),all tokens exceed B, are discarded.

* If a packet leaves the packet queue, a token is removedfrom the bucket. If the momentary depth of the tokenbucket is smaller than thresholdB, thresholdp,threshold, than B, P or I packets must wait,respectively.

* Let tk be the time packet k leaves the packet queue,b(tk) be the bucket depth at tk, then can easily bederived that:

1-4244-0569-6/06/$20.00 t2006 IEEE

ii (t T, t) = /j i (t T, t)i (8)

63

b(tk ) = min{Bi, b(tk_- ) + (tk tk-l )Rj 3 1- (10)It is worthy to note that the threshold of higher priority

class is smaller than the lower ones. This means a higherpriority packet might be eligible to be sent while at the sametime a packet of lower priority is not eligible. Thus highpriority packets can "borrow" bandwidth from the other lowerpriority packets.

If the packet Pi of frame F.k becomes the head-of-linepacket in the queue, the Rate Adaptation Algorithm isexecuted:

P,=Head Of Line(;Shape(Pj); /* according to mutti-threshold traffic shaper *

If Status(Pj)=not eligible

Discard(Pj);Discard(P:PI, EFk);

Else

Send(Pj); D

V. TEST AND RESULTS

The testbed of our architecture is a real softwareimplementation developed under Linux. In the testbed we usenormal desktop computers with 3GHz CPU clock, 512MBRAM.

In the experiments, we consider a subtree in the multicasttopology. The parent node is connected to a video-on-demandserver and has two clients. The experimental network isconfigured so that the links connecting the first client isuncongested, while the link connecting the second client isbottlenecked. In order to make the link characteristics realistic,we also simulate random packet loss due to interference for thesecond child node, which is about 3 - 500. As recommended inRFC3350 [15] we choose the RTCP-RR feedback period of 5s.The video-on-demand server is the DarwinStreamingServerdeveloped by Apple, which generated an H.264-encoded video.The average video rate is 128kbps, which corresponds to about28packetls.

Figure 6 shows that the root node tries to keep the sendingrate around the available bit rate, independent of how thearrival rate is. In the case of our experiment, the arrival H.264video traffic exhibits self-similar characteristics with theaverage arrival rate of 28packets/s. From the figure, we can seethat the controlled rate is some time smaller than the availablebandwidth. This is because when a packet of a video frame isdropped according to our algorithms, the other packetsbelonging to that frame is also discarded.

Loss performance of the Rate Adaptation Algorithm isshown in Figure 7. In each graph we show the number of I, P,B frames received at the clients in case of no congestion,congestion with rate adaptation and congestion without rateadaptation.

The client 1 receives the whole video stream withoutcongestion (128kbitps or 28packet/s - the rightmost bars in

Figure7, b, c); in contrast, the link between the root node andthe child node 2 is congested with the available bandwidthvarying between: 25.0, and 15. Opacket/s. We test theperformance of our algorithm in two scenarios: when the rootnode performs rate adaptation (the middle bars in Figure 7a, b,c) or does not perform rate adaptation (the leftmost bars). Theresults show that when the available rate is under 20packetls,the perceived quality of received video stream degradesremarkably, since I frames can hardly get through the bottleneck. However, if rate adaptation is deployed at the root node,the video quality is quite acceptable even in case drop rate isabout 5000 (available rate iSpacket/s), since B and P packetsare dropped instead of I frames. The effect is that at thereceiver, the image movements are not very smooth, but thereis far less distortion as in the case of no rate adaptation, as thereceiver can reconstruct images based on information in Iframes. This means that the perceived video quality at thereceiver improves remarkably by using the Rate ControlAlgorithm.

30available rate at bottle necktargeted output ratesending rate

25

320 --- ----------------- -- - - - - - - - -15

10 _

20 40 60 80 100 120 140 160 180 200 220 240 260 280Time (s)

Figure 6. Rate performance in case of congestion with available bandwidth20packet/s

VI. CONCLUSIONS AND DISCUSSION

In the article, we have discussed about some specificproblems when transmitting compressed video traffic onoverlay networks. We also describe our architecture thatsupports video services on the overlay. In our approaches, wedeveloped two mechanisms that support improvement of QoSfor video services and efficiently utilize the network resourcein terms of bandwidth, namely the Link Estimation Algorithmand the Rate Control Mechanism. The Link EstimationAlgorithm makes use of a heuristic method to differentiatecongestion loss and interference loss. Based on thatinformation, the Rate Control Algorithm can adapt the sendingrate of video traffic on the next hop. Results from realimplementation show that the new mechanisms remarkablyimprove the user's QoS.

The Rate Estimation Algorithm is developed based on anassumption that interference loss varies slowly. In a fastchanging environment, more sophisticated method should beimplemented. Link estimation is considered as the mostcomplicated and interesting issue. Also, the application-layer

1-4244-0569-6/06/$20.00 t2006 IEEE 64

multicast in our implementation does not support topologydynamicity. An adaptive FEC mechanism is also underdevelopment. These issues would be the interesting subjects fora future research.

4096 WAMailable roe: 20packet/s B Frames received

P Frames receivedI Frames received1024

. 256

640

2

without rate adaptaion with rate adaptation

(a)

no congestion

4096 FAvailable rate: 20packet/s

1024

. 256

j 64

16

4

2

withoutrate adaptation withrute adaptation

(b)

B Frames receivedP Frames receivedI Frames received

no congestion

4096FAvailable rate: 15packctts

1024 0

B fiames received

P frames receivedm I fifames received

256

It 64-

Z l-

4-

2Lwitiout rate adaptation with rate adaptaion

(c)

no congestion

REFERENCES

[1] J. Beran, R. Sherman, M. Taqqu, and W. Willinger, "Long-rangedependence in VBR video traffic," IEEE Transactions onCommunications, 43, Feb.-March-April 1995.

[2] 0. Rose, "Statistical properties of MPEG video traffic and their impacton traffic modelling in ATM systems," in 20th Annual Conference onLocal Computer Network, February 1995.

[3] B. Cain, S. Deering, I. Kouvelas, B. Fenner, and A. Thyagarajan, "RFC3376: Internet Group Management Protocol Version 3," IETF October2002

[4] D. Waitzman, C. Partridge, and S. Deering, "RFC 1075: Distance VectorMulticast Routing Protocol," IETF November 1988

[5] J. Moy, "RFC 1584: Multicast Extensions to OSPF," IETF March 1994[6] Suman Banerjee, and Bobby Bhattacharjee, "A Comparative Study of

Application Layer Multicast Protocols," Technical Report, University ofMaryland 2002

[7] Striegel, A., and Manimaran, G.;,"A survey ofQoS multicasting issues,"IEEE Communications Magazine, 40, June 2002

[8] Ganjam, A., and Zhang, H., "Internet multicast video delivery,"Proceedings of the IEEE, 93, January 2005

[9] Charikar, M.; Naor, J., and Schieber, B., "Resource optimization in QoSmulticast routing of real-time multimedia," IEEE/ACM Transactions onNetworking, 12, April 2004

[10] N. H. Thanh, M. Kleis, T. Schierl, T. Hirsch, and D. Haage,,,Perfomance evaluation of an overlay open architecture for multimediastreaming," Proceedings ofIEEE ISIMP'04, Hong Kong, October 2004.

[11] J. G. Apostolopoulos, "Reliable video comunication over lossy packetnetworks using multiple state encoding and path diversity," Proc. SPIEVisual Communication and Image Processing, pp. 392-409, Jan. 2001.

[12] Ruixiong Tian, Qian Zhang, Zhe Xiang, Yongqiang Xiong, Xing Li, andWenwu Zhu, " Robust and Efficient Path Diversity in Application-LayerMulticast for Video Streaming," IEEE Transactions on Circuits andSystems for Video Technology, 15, August 2005

[13] Jian Ni, and Danny H. K. Tsang, "Large-Scale Cooperative Caching andApplication-Level Multicast in Multimedia Content Delivery Networks,"IEEE Communications Magazine, May 2005.

[14] S. Banerjee, C. Kommareddy, K. Kar, B. Bhattacharjee, and S. Khuller,"Construction of an efficient overlay multicast infrastructure for realtimeapplications," Proc. IEEE INFOCOM, vol. 2, pp. 1521-1531, Apr.2003.

[15] H. Schulzrinne, et al., "RFC3550: RTP: A Transport Protocol for Real-Time Applications," IETF July 2003

[16] F. Agharebparast, V. C. M. Leung, "A new traffic rate estimation andmonitoring algorithm for the QoS-enabled Internet," IEEEGLOBECOM 2003

[17] M. Jain, C. Dovrolis, "End-to-end estimation of the available bandwidthvariation range," Proceedings of ACM SIGMETRICS. Banff, Canada,June 2005

[18] iBeam Broadcasting Corp. http://www.ibeam.com.[19] Akamai Technologies, Inc. http://www.akamai.com

Figure 7. Loss performance ofthe rate adaptation algorithm in case lost rate(a) 25packet/s and (b) 20packet/s and (c) 15packet/s, respectively

1-4244-0569-6/06/$20.00 t2006 IEEE 65