ABRC: An End-to-End Rate Adaptation Scheme for Multimedia Streaming over Wireless LAN*

Transcription

1 ARC: An End-to-End Rate Adaptaton Scheme for Multmeda Streamng over Wreless LAN We Wang Soung C Lew Jack Y Lee Department of Informaton Engneerng he Chnese Unversty of Hong Kong Shatn N Hong Kong {wwang2 soung yblee}@ecuhkeduhk Abstract he rapd growth of wreless LAN (WLAN) deployments wll brng about many novel moble applcatons Among them wll be real-tme multmeda streamng applcatons runnng on whch may nterfere wth current data applcatons runnng on hs paper s a frst attempt to nvestgate how to ensure the performance of these two groups of applcatons when they co-exst over a WLAN oward ths end we have desgned and mplemented a rate adaptaton scheme called Adaptve-uffer Rate Control (ARC) for multmeda streamng over WLAN ARC has two dstngushng features compared wth other schemes: ) It can acheve arbtrary bandwdth allocatons between and n the WLAN as opposed to prevously proposed frendly schemes whch can only acheve unform bandwdth allocatons; 2) he majorty of prevously proposed flexble bandwdth-allocaton schemes acheve arbtrary bandwdth allocatons by prortzng and schedulng packet transmssons wthn network equpment (e wthn routers base statons etc) In contrast ARC s an end-to-end applcaton-layer soluton that does not requre changes to current WLAN products makng t more readly deployable over exstng networks Keywords Rate control WLAN 802 Multmeda streamng andwdth allocaton -frendly protocols FRC Introducton In the last few years wreless networks based on the IEEE 802 standard have been undergong accelerated deployment n homes enterprses and publc hotspots such as arports and hotels he majorty of the wreless LAN (WLAN) deployments use the Infrastructure Mode of 802 n whch the termnal devces communcate wth each other as well as wth machnes n the wred networks va an access pont (AP) An AP usually has two nterfaces: an 802 nterface for communcaton n the WLAN and an Ethernet nterface for connecton to the wred Internet nfrastructure Currently the prevalent applcatons n WLANs are data applcatons such as web browsng emal delvery and hs work s sponsored by the Areas of Excellence scheme establshed under the Unversty Grant Commttee of the Hong Kong Specal Admnstratve Regon Chna (Project Number AoE/E-0/99) fle downloadng Wthn a WLAN these applcatons generate mostly downlnk traffc from the AP to the wreless statons he upstream traffc s generally much lghter Due to the relatvely low bandwdth of the 802 nterface compared wth the Ethernet nterface (eg the maxmum data rate of 802b s Mbps whle the maxmum data rate of a typcal Ethernet s 00 Mbps) the AP could become a sgnfcant bottleneck for downlnk traffc Although the popular applcatons on WLANs today are data applcatons we antcpate that as WLANs become even more wdespread and ubqutous real-tme applcatons such as voce over IP and vdeo streamng wll also be n demand hese applcatons typcally use as the transport protocol and have strngent and delay requrements An mportant ssue s how to satsfy the requrements of real-tme applcatons wthn the WLAN and at the same tme ensure harmonous co-exstence wth other data applcatons For harmonous co-exstence wth the real-tme applcatons could employ -frendly protocols on top of (eg see []) hese protocols can ensure that the bandwdth s shared n a far manner among and streams Essentally the bandwdth s dvded evenly among all streams When there s no competng traffc streams can also fully make use of the avalable WLAN bandwdth hs makes t possble to support bandwdthadaptve applcatons over the -frendly protocols (eg vdeo streamng n whch the bt rate s adapted accordng to the bandwdth avalable) -frendly protocols however suffer from two shortcomngs Frst one cannot fne-tune the proportons of bandwdths allocated to real-tme applcatons and applcatons n a non-unform manner hat s one cannot allocate more (or less) bandwdths to real-tme applcatons than applcatons Second most -frendly protocols proposed to-date ether attempt to mmc the behavor of [2] or explctly adjust ts sendng rate based on equatons whch model the of the flow under the same condton of round-trp tme and packet loss rate [3] One sde effect of emulatng behavor s that such -frendly protocols wll also nhert certan shortcomngs of For example when a packet loss s detected -frendly protocols may reduce the nput data rate (as n regular ) regardless of whether the packet loss s due to traffc WCNC 2004 / IEEE Communcatons Socety /04/$ IEEE

2 congeston or random nose n the wreless medum In the latter case the nput data rate should not be reduced because dong so does not solve the packet loss problem and may degrade the qualty of servce unnecessarly o allocate bandwdths n WLAN the most drect way s to schedule packet transmssons on the AP downlnk Schedulng schemes such as Prorty Queung and Weghted Far Queung (WFQ) mplement multple queues for dfferent flows or traffc classes [5][6] However the AP buffers n most of today s commercal products are smple FIFO queues that are shared by all traffc We may have to lve wth such FIFO queues for some tme to come consderng the large amount of such 802 equpment already deployed o address the problems and ssues outlned above we propose n ths paper an end-to-end rate adaptaton scheme called Adaptve-uffer Rate Control (ARC) that can acheve arbtrary bandwdth allocatons between and at the AP We have mplemented and evaluated ts performance n a real WLAN testbed Compared wth prevous work ARC has two major dstngushng features: ) It acheves desred bandwdth allocatons n a totally endto-end way hat s t can be appled to the current 802 commercal products wthout any modfcatons on them makng t more readly deployable over exstng networks o the best of our knowledge ARC s the frst end-to-end approach proposed to provde bandwdth allocatons between and traffcs n WLAN 2) It acheves -frendlness n a dfferent way than the prevous -frendly schemes As wth these frendly schemes ARC can make sure that streams do not hog the bandwdth at the expense of connectons; and when there are no competng streams streams can fully make use the entre WLAN bandwdth However ARC does ths wthout tryng to mmc the behavor of Consequently t does not nhert problems of n wreless networks 2 Adaptve-uffer Rate Control Scheme o explan the ARC scheme we consder the network set-up as shown n Fg We assume that the ARC sender s located close to the AP and connected to t through an Ethernet An example of an ARC sender s a vdeo server If the orgnal vdeo source s at a remote locaton the server shown n Fg could be a local proxy server that obtans the vdeo data from the orgnal vdeo source for feedng to the recevers wthn the WLAN he sender could be a server for FP or other based applcatons Although the sender s shown n Fg as beng close to the WLAN and connected to t through an Ethernet t could n general be located at a dstance wthn the Internet ARC s an applcaton-layer protocol over In ARC the recever collects data and statstcs on ncomng packets and feed them back to the sender at regular ntervals ased on the feedback the sender estmates the buffer occupances of and traffc n the AP downlnk queue from whch the relatve bandwdth usage between and s obtaned he sender then compares the relatve bandwdth usage wth the target bandwdth allocaton and adjusts ts sendng rate accordngly n a dynamc fashon Specfcally the tasks performed by the ARC scheme can be broken down as follows: ) Estmaton of and buffer occupances to obtan the current relatve bandwdth usage; 2) Adjust the sendng rate based on ) to acheve the desred relatve bandwdth allocatons Fgure Network setup for ARC scheme 2 Relatonshp between andwdth Usage and uffer Occupances ARC attempts to adjust the buffer occupancy of ts packets at the AP to acheve the desred bandwdth allocaton wth respect to the co-exstng traffc Denote the buffer occupancy of and by and respectvely If the queue at the AP s FIFO t s obvous that λ λ = () where λ and λ are the s (or output rates) of and at the queue respectvely Denote the desred rato of bandwdth allocaton by k = λ / λ (2) If we knew the value of then the target buffer occupancy for traffc needed to acheve the desred bandwdth-allocaton rato s = k (3) In practce due to the dynamc nature of operaton the value of wll change over tme A key ngredent n ARC s a method for trackng such change so that the target buffer occupancy for can be adjusted accordngly to mantan the desred k hs s detaled n the next two subsectons WCNC 2004 / IEEE Communcatons Socety /04/$ IEEE

3 22 Estmaton of uffer Occupancy o estmate the buffer occupancy the sender adds a sequence number to every packet sent In the th feedback packet the recever provdes the sequence number ] Seq recv of the most recently receved packet Upon recevng the feedback the sender estmates the buffer occupancy at the end of th feedback nterval by [ = Seqsend [ Seqrecv[ (4) where Seq send [ s the most recent packet sent out by the sender when the th feedback packet s receved Note that (4) s only an approxmate upper bound because when the sender receves the feedback the current Seq send could be larger than the Seq send when Seq recv was measured on the recever he naccuracy of (4) s caused by the transmsson tme of the feedback packet (the transmsson tme as defned here ncludes all the overhead ncurred by the 802 protocol such as backoff physcal preamble and InterFrame Space etc) From our experments we have observed that the error n (4) s only one or two packets o estmate the buffer occupancy ARC makes use of packet nter-arrval tmes regstered by the recever Suppose that the AP queue were flled by packets only the nter-arrval tme for two consecutve packets observed by the recever would be the transmsson tme of one packet denoted as where also ncludes the varous 802 protocol overheads When the AP queue has a mx of and packets the average nter-arrval tme of the two consecutve packets observed by the recever mx wll be larger than mx s related to the rato of and buffer occupances At the end of the th feedback nterval f that the buffer occupancy of s twce that of (e [ = 2 [ ) then the average nter-arrval tme of packets n the th feedback nterval mx [ should be the transmsson tme of a packet plus two transmsson tmes of a _DAA packet plus α tmes the transmsson tme of one _ACK packet Generally α = or 2 dependng on whether the sends a _ACK for every packet or every two packets he reason for addng the transmsson tme of _ACK as part of mx [ s that the wreless channel s shared by all wreless statons herefore the sendng of upstream _ACKs wll also ncrease the delay of the downstream packets If we gnore the transmsson tme of _ACK snce t s relatvely small [ compared wth _DAA then approxmately mx [ has a drect relatonshp wth the buffer occupances as follows: [ + k[ mx = (5) k[ where ] = [ ] [ ] s the rato between the and buffer occupances for the th feedback nterval If the has the same packet length of that s = then [ ( + k[ ) = (6) mx In the mplementaton we can smply use the mnmum nterarrval tme observed by the recever as an estmaton of countng on the fact that occasonally two packets wll be transmtted n successon even when there are packets n the AP queue So when the recever measures mx [ the buffer occupancy of the th feedback nterval can be estmated by mx[ [ [ = (7) 23 Sendng Rate Adjustment Equaton (7) provdes us wth a way to track the change n buffer occupancy he ARC sender can then dynamcally adapt ts sendng rate to mantan a certan rato k between and buffer occupances he sendng rate adjustment s a two-step process he frst step s to set up a target buffer occupancy to follow the changes of the buffer occupancy so that the rato between the and buffer occupances can be mantaned at or zoomed nto k (e to acheve equalty n (3)) he second step s to adjust the sendng rate to let the buffer occupancy narrow nto upon recevng the feedback from the recever For the frst step the sender can estmate the current buffer occupancy [ on recevng the th feedback packet based on (7) When t s tme to adjust the target buffer occupancy the can be set to = k [ accordng to (3) We may want to make adjustment Note that strctly speakng the assumpton of equal length for and packets s not necessary If we defne buffer occupances n terms of numbers of bytes (or amounts of work) rather than packets equaton (6) wll reman vald even for and packets of dfferent sze WCNC 2004 / IEEE Communcatons Socety /04/$ IEEE

4 nterval several tmes the feedback nterval so as to leave tme for the ARC to acheve the prevously set For the second step besdes sequence number and nterarrval tme the recever also measures the over a feedback nterval t by countng the number of packets receved durng the t seconds Let W denote the (n packets/second) of the th feedback nterval Note that W s related to mx [ by W = / mx [ When the sender receves the th feedback packet t estmates the bandwdth of the W + ( + ) th feedback nterval as Smlar to the bandwdth estmatons of many other network protocols W + can be smply set tow ; or alternatvely a wndow average or an exponental average on can be used as the estmate wth the W W averagng/smoothng perod set accordng to the responsveness desred and the bandwdth fluctuatons observed From the feedback the sender also derves the current buffer occupancy [ accordng to (4) For the ( + )th feedback nterval we expect the number of packets leavng the AP queue to be W + t Let S + be the sendng rate durng the ( + ) th nterval hen the number of packets enterng the AP queue durng the ( + )th nterval s S t + S t W t he change n buffer occupancy s + + he target change n buffer occupancy s [ Equatng these two terms and rearrangng we have S ( + W t [ ) / t = + + (8) 3 Expermental Evaluaton o evaluate the performance of the ARC scheme we have mplemented and tested t n a real network confgured as n Fg he sender and recevers are FP server and clents he ARC mplementaton uses a feedback nterval of one second (e t = ) and adjustment nterval of three seconds For bandwdth estmate of the next nterval W = W W + we smply let + the bandwdth regstered by the recever for the current feedback nterval hs makes the ARC scheme somewhat aggressve n response to bandwdth changes he nteractons between ARC sender and recever are summarzed below: ) For each feedback nterval over one second the recever measures the average of the ARC stream collects the sequence number of the most recently receved packet hs nformaton s fed back to the sender at the end of the one second 2) After recevng a feedback packet the sender estmates the buffer occupancy [ and the average W + bandwdth of the next second 3) Every three seconds the sender estmates the buffer occupancy It then adjusts the to k where k s the desred bandwdth allocaton If the new computed s below a threshold 5 (e < 5 ) let = 5 hs s to deal wth the case when there s no competng traffc n the AP y mantanng a mnmum ARC scheme can make full use of the wreless channel whle others are not usng t 4) Every second adjust the sendng rate accordng to (8) 3 andwdth Allocaton Results he frst set of our experments explores whether ARC allocates bandwdths accordng to the targets able shows the results wth one ARC connecton and one FP connecton able 2 shows the results wth one ARC connecton and two FP connectons We see that for most of the cases ARC can acheve the desred bandwdth allocaton rather well able One ARC coexsts wth one connecton andwdth allocaton factor k ARC able 2 One ARC coexsts wth two connectons andwdth allocaton factor k ARC 2 otal We would lke to pont out that ARC treats all traffc as a whole regardless of how many actual connectons there really are As a result ARC wll allocate bandwdth to the stream wth respect to the total bandwdth of all other streams rather than wth respect WCNC 2004 / IEEE Communcatons Socety /04/$ IEEE

5 the bandwdth of a partcular stream As a matter of fact n general t allocates bandwdth to the ARC stream wth respect to sum total of all other traffc ncludng other streams as well f any hus the value of k s the rato of the bandwdth allocated to the ARC stream wth respect to aggregate bandwdth of all other streams andwdth Comparson wth a -frendly Congeston Control Scheme In our second set of experments we compare the dynamc behavors of ARC wth the well-known -frendly Rate Control (FRC) scheme [3] FRC s an equaton-based frendly congeston control mechansm whch adjusts ts sendng rate as a functon of the measured rate of loss events where a loss event conssts of one or more packets dropped wthn a sngle round-trp tme he reader s referred to [3] for detals on FRC he FRC mplementaton used n our experments was downloaded from ts offcal webste [4] wth some modfcatons on the recever to record the s over tme We frst examne the operatons of FRC and ARC n solaton Fgure 2 shows the protocol behavors of FRC and ARC when each of them s the only traffc stream wthn the WLAN he bandwdths recorded over tme are the numbers of bts receved by the recever over successve one-second ntervals andwdth FRC ARC me (s) Fgure 2 Dynamc bandwdth usage of FRC and ARC when there s no other competng traffc Smlar to FRC also has the slow start and congeston control phases As can be seen n Fg 2 after beng started FRC needs more than 20 seconds to zoom to full utlzaton of the WLAN bandwdth hs s due to ts desgn prncple of not aggressvely seekng out avalable bandwdth he tme needed for achevng the equlbrum s rather long consderng that the R s rather short n ths experment Usually R s no more than several hundreds of mllseconds In contrast ARC makes full use of the WLAN bandwdth rght from the start of the experment hs s attrbuted to the operaton of ARC n whch t tres to keep to AP queue nonempty at all tme so that the AP always has some packets to transmt andwdth 5 FRC me (s) ARC me (s) Fgure 3 Dynamc bandwdth usage of FRC /ARC versus bandwdth usage of competng traffc Fgure 3 shows the bandwdth-usage evolutons for FRC and ARC when there s one competng connecton Here the bandwdth allocaton factor k of ARC s set to one so as to make ARC comparable wth FRC he R wthn WLAN s qute small so that s sendng rate s lmted by the advertsed wndow rather than by the congeston wndow hat s the maxmum value of advertsed wndow (64 Kbytes for the socket API we used) s quckly reached whle the congeston wndow s stll ncreasng FRC does not ncorporate an advertsed wndow lmt It only tres to emulate lmtaton of caused by congeston wndow lmt hus even after has reached ts advertsed wndow lmt FRC contnues to ncrease ts bandwdth usage untl t causes buffer overflow at the AP efore the buffer overflows and after the advertsed wndow lmt s reached (between 45 sec and 75 sec n Fg 3) FRC can grab more bandwdth than he of can be estmated by Max Advertsed Wndow dvded by R hroughput of decreases because Max Advertsed Wndow remans constant whle R ncreases R ncreases because FRC contnues to flood the AP buffer and causes ts total occupancy to contnue to ncrease After 75 sec AP buffer overflow occurs and both packets from and FRC start to be dropped Upon detecton of lost packets RFC mmedately reduces ts rate Although also decreases ts congeston wndow upon packet loss detecton the decreased congeston wndow s stll larger than the advertsed wndow Meanwhle the R has decreased because FRC has already decreased ts sendng rate hus the of ncreases (between 75 sec and 90 sec) As can be seen n Fg 3 for a sustaned perod of tme WCNC 2004 / IEEE Communcatons Socety /04/$ IEEE

6 (between 50 sec and 95 sec) the bandwdth usage s not allocated n a unform and far manner contrary to the desgn objectve of FRC In contrast as llustrated n the rght part of Fg 3 ARC tracks and follows the changes of much more closely Although there are stll fluctuatons the perods are much smaller (or frequency components much hgher) he mplcaton s as follows ake a vdeo server as an example Suppose that VR (varable bt rate) encodng s used to adapt the vdeo bt rate to the sendng rate Unless very large buffers are used at the encoder and the decoder (wth the consequence of hgher delays at the encoder and decoder) one cannot smooth the fluctuatons n bandwdth usage of FRC because the fluctuatons have very low frequency components As a result the vdeo qualty tends to vary perodcally over tme despte there s only one competng connecton hs varaton of vdeo qualty s self-nduced rather than due to changes n network actvty Although not shown here due to lmt space our expermental results beyond 90 sec on the left part of Fg 3 exhbt contnuous long-term oscllatory behavor he average of FRC s hgher than that of FRC n fact fals to acheve unform bandwdth allocatons wth wthn the WLAN Wth ARC the oscllatons have much smaller perods As a result a smaller buffer can be used at the encoder and decoder to smooth out the fluctuatons and the vdeo qualty can be mantaned at a more consstent level than that wth FRC In addton the targeted unform bandwdth allocaton n ths case s acheved after averagng out the oscllatons of ARC and 4 Dscussons Although the competng traffc n ths paper s the dervaton n Secton 2 s ndependent of the partculars of herefore ARC s not lmted to the case of coexstng wth ARC can also be used when there are other co-exstng traffc types ncludng other ARC streams When there are more than one ARC streams addtonal constrants need to be met to mantan a stable system For a partcular ARC stream let us defne β = k ( k +) where β s the proporton of the total bandwdth n the WLAN allocated to the th ARC stream For example f k s one then the ARC stream wll be allocated 50% of the total bandwdth If there are n ARC connectons competng wth several connectons for system stablty β < he remanng bandwdth proporton connectons n = n = β s farly shared by From the analyss n the prevous secton t s clear that ARC wll not have the shortcomngs of and frendly protocols n wreless networks such as degraded due to the nablty to dstngush between packet losses due to traffc congeston and random bt error hs s because unlke FRC ARC does not adjust ts sendng rate based on detecton of lost packets and therefore lost packets due to random wreless nose wll not cause t to decrease ts sendng rate Our experment results also valdate ths Due to the page lmt we wll present such results n a separate paper 5 Conclusons In ths paper we have presented an end-to-end rate control protocol called ARC to acheve any desred bandwdth allocatons between and traffc n the WLAN he desgn of ARC s based on an analytcal framework o test ts performance n practce we have mplemented ARC n a WLAN testbed he experment results valdate the ablty of ARC to acheve good bandwdth-allocaton performance as ntended We have also compared the performance of ARC wth a typcal -frendly rate control protocol named FRC Our results show that ARC does not have a number of the shortcomngs of FRC n wreless networks such as mprecse bandwdth allocaton long-term oscllatory behavor and unnecessary degradaton due to random wreless nose Last but not least unlke many prevous schemes proposed n the lterature ARC acheves bandwdth allocatons n a totally end-to-end way so that t can be appled to the current nstalled base of commercal WLAN products wthout any modfcatons on them As an applcaton-layer protocol t s readly deployable over the exstng Internet nfrastructure References [] S Floyd and K Fall Promotng the use of end-to-end congeston control n the Internet Networkng IEEE/ACM rans on Vol 7 Aug 999 pp [2] R Rejae M Handley and D Estrn RAP: An end-to-end ratebased congeston control mechansm for realtme streams n the Internet Proc INFOCOM 99 vol 3 Mar 999 pp [3] S Floyd et al Equaton-based congeston controlfor uncast applcatons Proc ACM SIGCOMM Aug 2000 pp [4] [5] Law K L E he bandwdth guaranteed prortzed queung and ts mplementatons Proc GLOECOM 97 vol 3 Nov 997 pp [6] M Katevens S Sdropoulos and C Courcoubets Weghted round-robn cell multplexng n a general-purpose AM swtch chp IEEE JSAC Oct 99 [7] Y R Yang Nn Sk Km and S S Lam ransent behavors of frendly congeston control protocols Proc INFOCOM 0 vol 3 Apr 200 pp WCNC 2004 / IEEE Communcatons Socety /04/$ IEEE