Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
0Activity
0 of .
Results for:
No results containing your search query
P. 1
Helzer

Helzer

Ratings: (0)|Views: 3 |Likes:
Published by Griffin Boyce

More info:

Published by: Griffin Boyce on Jan 21, 2014
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

01/21/2014

pdf

text

original

 
Congestion Control for Multimedia Streaming withSelf-Limiting Sources
Josh Helzer (student)
University of Nebraska–LincolnLincoln, Nebraska 68588-0115
 jhelzer@cse.unl.eduLisong Xu (faculty)
University of Nebraska–LincolnLincoln, Nebraska 68588-0115
xu@cse.unl.edu
1. INTRODUCTION
In the past few years we have witnessed an explosive growthin the usage of media streaming applications. For instance,according to a recent study by AccuStream IMedia Research,14.2 billion video streams were served in 2004, an 80% in-crease compared to 2003, and the number is forecast to reach21 billion in 2005. The rapid growth in the usage of stream-ing media over the Internet has heightened [3] the need fora congestion control protocol suitable for streaming media.Among the proposed streaming-media congestion controlprotocols, TCP-Friendly Rate Control (TFRC) [2] is oneof the promising solutions, and is currently being adoptedin several Internet standards. TFRC maintains an equal orlesser average sending rate as competing TCP connections(referred to as
 TCP Friendly 
), while providing a relativelysmooth sending rate to help packets to meet the real-timeconstraints required by streaming media.Media sources can be divided into two classes:
 greedy 
 or
 self-limiting sources 
. The former, including pre-recorded mediasources, send data as fast as allowed by the congestion con-trol protocol, whereas the latter, including live media sour-ces, cannot transmit data faster than their encoding rate [5].For a self-limiting source, the ideal sending rate should bethe minimum of its encoding rate and the network fair sharerate (i.e., the average sending rate of competing TCP con-nections). If a congestion control protocol can provide thisideal rate for a self-limiting source, it is
 Self-Limiting Source Friendly 
. However, it has been reported [5] that TFRC isnot self-limiting source friendly, since the average sendingrate achieved by TFRC may be much less than the idealone.We propose Equation-based Leaky-Bucket-regulated congEs-tion control (ELBE), a new congestion control protocol forthe streaming of self-limiting media sources over the Inter-net. Our preliminary simulation results show that ELBE isboth TCP friendly and self-limiting source friendly.
2. SELF-LIMITING SOURCE UNFRIEND-LINESSOFTFRC
For a self-limiting media source TFRC maintains a trans-mit buffer [6] which is filled at the media encoding rate anddrained at the average TCP sending rate if the buffer is notempty. When there is a dramatic change in the average TCPsending rate, the media source may switch its average en-coding rate to a higher or lower one accordingly. To simplifythe description, we assume that the average TCP sendingrate is constant, and also that the average media encodingrate is constant. The instantaneous media encoding rate canstill vary, for example, when silence or stillness suppressionis employed.Let
 S 
avg
 denote the average sending rate that packets leavethe buffer and enter the network, and
 E 
avg
 denote the aver-age media encoding rates. Let TCP
avg
 and TCP
peak
 denotethe average and peak TCP sending rates, respectively. Aself-limiting source friendly protocol should achieve
 
avg
 =min(
avg
,
 TCP
avg
). However, since TFRC limits the in-stantaneous sending rate to be no more than TCP
avg
, wehave
 
avg
 
 min(
avg
,
 TCP
avg
). In particular, as long asan instantaneous encoding rate fluctuates around TCP
avg
,we have
 
avg
 <
 min(
avg
,
 TCP
avg
). Furthermore, whenthe instantaneous encoding rate is significantly larger thanTCP
avg
, some packets will be delayed in the buffer, anddropped if the buffer has a small capacity in order to main-tain a small packet latency. In this case,
 
avg
 may be muchless than min(
avg
,
 TCP
avg
). Therefore, TFRC is not self-limiting source friendly.
3. DUAL LEAKY BUCKET ALGORITHMOFELBE
ELBE regulates the traffic from a media source by the dualleaky bucket algorithm, as shown in Figure 1. The dualleaky bucket is usually used in networks with Quality of Service (QoS) support, such as ATM, Diffserv, and Intservnetworks, here we use it for media streaming over the best-effort Internet. For simplicity, below we assume that allpackets have the same size, and that one packet removesone token. The actual ELBE protocol will use a fluid dualleaky bucket algorithm to accommodate media sources withvariable packet sizes.ELBE sets
 
1
 >
 1,
 R
1
 = TCP
avg
,
 
2
 = 1, and
 R
2
 =TCP
peak
. With this setting, leaky bucket 1 limits aver-age sending rate
 
avg
 to be no more than TCP
avg
. Leakybucket 2 allows an instantaneous sending rate to be larger

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->