Architectural Considerations for Playback of Quality Adaptive Video over the Internet

Internet

RezaRejaie,MarkHandley,DeborahEstrin

UniversityofSouthernCaliforniaInformationSciencesInstituteMarinaDelRey,CA90292reza,mjh,estrin@isi.edu

Abstract

LackofQoSsupportintheInternethasnotpreventedrapidgrowthofstreamingapplications.Howevermanyoftheseapplicationsdonotperformcongestioncontroleffec-tively.Thusthereissignificantconcernabouttheeffectsonco-existingwell-behavedtrafficandthepotentialforcon-gestioncollapse.Inaddition,mostsuchapplicationsareunabletoperformqualityadaptationon-the-flyasavailablebandwidthchangesduringasession.

ThispaperaimstoprovidesomearchitecturalinsightsonthedesignofvideoplaybackapplicationsintheInternet.WepresentfundamentaldesignprinciplesforInternetap-plicationsandidentifyend-to-endcongestioncontrol,qual-ityadaptationanderrorcontrolasthethreemajorbuild-ingblocksforInternetvideoplaybackapplications.Wedis-cussthedesignspaceforeachofthesecomponents,andwithinthatspace,presentanend-to-endarchitecturesuitedforplaybackoflayered-encodedstoredvideostreams.

Ourarchitecturereconcilescongestioncontrolandqual-ityadaptationwhichoccurondifferenttimescales.Itex-hibitsaTCP-friendlybehaviorbyadoptingtheRAPproto-colforend-to-endcongestioncontrol.Additionally,itusesalayeredframeworkforqualityadaptationwithselectivere-transmissiontomaximizethequalityofthedeliveredstreamasavailablebandwidthchanges.Wearguethatthearchi-tecturecanbegeneralizedbyreplacingthesuggestedmech-anismforeachcomponentbyanotherfromthesamedesignspaceaslongasallcomponentsremaincompatible.

1.Introduction

TheInternethasbeenrecentlywitnessingrapidgrowthintheuseofaudioandvideostreaming.Althoughsome

sentsmanyofthecurrentstreamingapplicationsintheIn-ternet.Thegoalistomaximizetheoverallstableplaybackqualitywhileobeyingcongestioncontrolconstraints.Fur-thermoreneithertheservernortheclientsshouldrequireexcessiveprocessingpowerorstoragespace.

ThispaperaimstoprovideahighlevelarchitecturalviewofthedesignofplaybackvideoapplicationsfortheInter-net.AddressingdesignprinciplesforInternetapplicationsleadustoidentifycongestioncontrol,qualityadaptationanderrorcontrolasthreekeycomponentsforanyvideostreamingapplicationinsection2.Insection3,weexplorethedesignspaceforeachoneofthesecomponentsinthecontextofvideoplaybackapplicationsfortheInternetandsuggestamechanismforeachcomponentfromitsdesignspace.Ourmaincontributionistocomposethethreekeycomponentsintoacoherentarchitectureanddescribethein-teractionamongthesecomponentsinsection4.Insection5,wearguethatthearchitecturecanbeviewedasagenericarchitectureforvideoplaybackapplicationsaslongasthedifferentmodulesareproperlyintegrated.Finally,section6concludesthepaperandaddressessomeofourfuturework.

applications.

EveniftheInterneteventuallysupportsreservationmechanisms[30]ordifferentiatedservices[1],itislikelytobeonper-classratherthanper-flowbasis.Thus,flowsarestillexpectedtoperformcongestioncontrolwithintheirownclass.

BeingAdaptive

WiththeInternet’sbest-effortservicemodelthereisneitheranupperboundfordelaynoralowerboundforavailablebandwidth.Thequalityoftheserviceprovidedbythenetworkchangeswithtime.Furthermore,performingeffectivecongestioncontrolcouldresultinrandomandwidevariationsinavailablebandwidth.Applicationsmustbeabletocopewiththesevariationsandadaptivelyoperateoverawiderangeofnetworkconditions.

Streamingapplicationsareabletoadjustthequalityofdeliveredstream(andconsequentlyitsconsumptionrate)withlong-termchangesinavailablebandwidthandoperateinvariousnetworkconditions.Howeverthismechanismisapplicationspecific.Wecallthisqualityadaptation.RecoveryFromLoss

Packetsarerandomlylostinthenetworkmainlyduetocongestion.Althoughstreamingapplicationscantoleratesomeloss,itdoesdegradethedeliveredstreamquality.Tomaintainthereasonablequality,streamingapplicationsneedawaytorecoverfrommostlossesbeforetheirplayouttime.Suchalossrecoverymechanismisusuallyknownaserrorcontrol.Theeffectoflossonplayoutqualityisalsoapplicationspecific.

2.DesignPrinciples

Inasharedbest-effortnetworksuchastheInternet,thereareseveralprinciplesthatmustbefollowedinthedesignofanynewapplicationincludingstreamingapplicationsasfollows:

SocialBehavior

TheInternetisasharedenvironmentanddoesnotmicro-manageutilizationofitsresources.Sinceflowsarenotisolatedfromeachother,amis-behavedflowcanaffectotherco-existingflows.Thusendsystemsareexpectedtobecooperativeandreacttocongestionproperlyandpromptly[7,13].Thegoalistoimproveinter-protocolfairnessandkeeputilizationofresourceshighwhilethenetworkoperatesinastablefashion.

ThecurrentInternetdoesnotwidelysupportanyreser-vationmechanismorQualityofService(QoS).Thustheavailablebandwidthisnotknownaprioriandchangeswithtime.Thisimpliesthatapplicationsneedtoexperimenttolearnaboutnetworkconditions.Acommonapproachisthatapplicationsgraduallyincreasetheirtransmissionratestoprobeavailabilityofbandwidthwithoutseverelycongest-ingthenetwork[10].Whenanyindicationofcongestionisdetected,theyrapidlyback-offtheirtransmissionrate.Thisprocessisknownasend-to-endcongestioncontrolandisre-quiredforstabilityofthenetwork.Becauseofthedynamicsofthetraffic,eachflowcontinuouslyprobesandbacksofftoadaptitstransmissionratetotheavailablebandwidth.Itiscrucialtounderstandthatcongestioncontrolisanetworkdependentmechanismandmustbeequallydeployedbyall

2

3.DesignSpace

Beforewedescribeourproposedarchitecture,weex-plorethedesignspaceforthekeycomponentsandspecifyourdesignchoices.

3.1CongestionControl

ThemostwellunderstoodalgorithmforrateadaptationisAdditiveIncrease,MultiplicativeDecrease(AIMD)[5]usedinTCP[10],wheretransmissionrateislinearlyin-creaseduntilalosssignalscongestionandamultiplicativedecreaseisperformed.

Adominantportionoftoday’sInternettrafficconsistsofavarietyofTCP-basedflows[6].ThusTCP-friendlybehav-iorisanimportantrequirementfornewcongestioncontrolmechanismsintheInternetotherwisetheymayshutoutthewell-behavedTCP-basedtraffic.ByTCP-friendlywemeanthatanewapplicationthatcoexistswithaTCPflowalongthesamepathshouldobtainthesameaveragebandwidthduringasession.

TCPitselfisinappropriateforstreamingapplicationswithhardtimingconstraintsbecauseitsin-orderdeliverycouldresultinalongdelay.EvenmodifiedversionofTCPwithoutretransmission[9]exhibitsburstybehavior.SCP[4]andLDA[26]protocolstargetstreamingapplications.TheirgoalistobeTCP-friendly,howevertheywerenotexam-inedagainstTCPoverawiderangeofnetworkconditions.RAP[24]isarate-basedcongestioncontrolmechanismthatdeploysanAIMDrateadaptationalgorithm.RAPissuitedforstreamingapplicationsandexhibitTCP-friendlybehav-ioroverawiderangeofnetworkconditions.Anotherpoten-tialclassofrate-basedcongestioncontrolschemesisbasedonmodelingTCP’slong-termbehavior[20].Thereison-goingwork[8]toevaluatethestabilityofthesemechanisms.HoweverwehaveadoptedRAPforcongestioncontrolinourarchitecture.

3.2QualityAdaptation

Streamingapplicationsarerate-based.Oncethedesiredqualityisspecified,therealtimestreamisencodedandstored.Theoutputrateoftheencoderisadirectfunctionofthedesiredquality,theencodingschemeandthecontentofthestream.Althoughtheoutputrateoftheencodercouldvarywithtime,forsimplicityweassumethatencodergen-eratesoutputwithanear-constantbandwidth.Inthecontextofvideo,thistypicallyimpliesthattheperceivedqualityisinverselyproportionaltothemotioninthevideo.Remain-ingsmallvariationsinbandwidtharesmoothedoverafewvideoframesusingplayoutbuffering.

Incontrast,performingTCP-friendlycongestioncontrolbasedonanAIMDalgorithmresultsinacontinuouslyvari-abletransmissionrate.Thefrequencyandamplitudeofthesevariationsdependsonthedetailsoftherateadjust-mentalgorithmandthebehaviorofcompetingbackgroundtrafficduringthelifeoftheconnection.Themainchal-lengeforstreamingapplicationsistocopewithvariationsinbandwidthwhiledeliveringthestreamwithanacceptableandstablequality.Acommonapproachistoslightlydelaytheplaybacktimeandbuffersomedataattheclientsidetoabsorbthevariationsintransmissionrate[23].Themorethedataisinitiallybuffered,thewiderarethevariationsthatcanbeabsorbed,althoughahigherstartupplaybacklatencyisexperiencedbytheclient.Themainreasonthatwetar-getplaybackapplicationsisbecausetheycantoleratethisbufferingdelay.Foralong-livedsession,ifthetransmis-sionratevarieswidelyandrandomly,theclient’sbufferwilleitherexperiencebufferoverfloworunderflow.Underflowcausesaninterruptioninplaybackandisveryundesirable.Althoughbufferoverflowcanberesolvedbydeployingaflowcontrolmechanismitthenmeansthatthefairshareofbandwidthisnotfullyutilized.

Totacklethisproblem,acomplementarymechanismfor

3

bufferingisrequiredtoadjustthequality(i.e.consumptionrate)ofstreamswithlongtermvariationsofavailableband-width.Thisistheessenceofqualityadaptation.Acom-binationofbufferingandqualityadaptationisabletocopewithrandomvariationsofavailablebandwidth.Shorttermvariationscanbeabsorbedbybufferingwhereaslongtermchangesinavailablebandwidthtriggerthequalityadapta-tionmechanismtoadjustthedeliveredqualityofthestream.Thereareseveralwaystoadjustthequalityofapre-encodedstoredstream,includingadaptiveencoding(i.etranscoding),switchingbetweenmultipleencodedversionsandhierarchicalencoding.Onemayadjusttheresolutionofencodingon-the-flybyre-quantizationbasedonnetworkfeedback[2,19,27].However,sinceencodingisaCPU-intensivetask,serversareunlikelytobeabletoperformon-the-flyencodingforlargenumberofclientsduringbusyhours.Furthermore,oncetheoriginaldatahasbeenstoredcompressed,theoutputrateofmostencoderscannotbechangedoverawiderange.

Inanalternativeapproach,theserverkeepsseveralver-sionsofeachstreamwithdifferentqualities.Asavailablebandwidthchanges,theserverswitchesplaybackstreamsanddeliversdatafromastreamwithhigherorlowerqualityasappropriate.

Withhierarchicalencoding[12,15,16,29],theservermaintainsalayeredencodedversionofeachstream.Asmorebandwidthbecomesavailable,morelayersoftheen-codingaredelivered.Iftheaveragebandwidthdecreases,theservermaydropsomeoftheactivelayers.Layeredap-proachesusuallyhavethedecodingconstraintthatapartic-ularenhancementlayercanonlybedecodedifallthelowerqualitylayershavebeenreceived.

Thereisadualitybetweenaddingordroppingoflay-ersinthelayeredapproachandswitchingstreamswiththemultiply-encodedapproach.Thelayeredapproachhassev-eraladvantagesthough:itismoresuitableforcachingbyaproxyforheterogeneousclients[25],itrequireslessstorageattheserversideanditprovidesanopportunityforselec-tiveretransmissionofthemoreimportantinformation.Themainchallengeofalayeredapproachforqualityadapta-tionisprimarilyinthedesignofanefficientaddanddropmechanismthatmaximizesoveralldeliveredqualitywhileminimizingdisturbingchangesinquality.

3.3ErrorControl

Streamingapplicationsaresemi-reliable,i.e.theyre-quirequalityinsteadofcompletereliability.However,withmostencodingschemes,packetlossbeyondsomethresholdwilldegradetheperceivedplaybackqualitybecausegoodcompressionhasremovedtemporalredundancyandimagecorruptionthusbecomespersistent.Thereforetheseappli-cationsmustattempttolimitthelossratebelowthatthresh-

oldforagivenencoding.

Techniquesforrepairingrealtimestreamsarewellknown[22],andincluderetransmission[21],FEC[3],inter-leavingandredundanttransmission.Theappropriaterepairmechanismisselectedbasedonthelevelofreliabilitythatisrequiredbytheapplicationcodec,thedelaythatcanbetoleratedbeforerecovery,andtheexpectedormeasuredlosspatternthroughoutthesession.

Inthecontextofunicastdeliveryofplaybackvideo,re-transmissionisanaturalchoice.Theonlydisadvantageofretransmission-basedapproachistheretransmissiondelay,butinthecontextofnon-interactiveplaybackapplications,clientbufferingprovidessufficientdelaytoperformretrans-mission.Moreoverretransmissioncanbeperformedse-lectively,whichnicelymatchesourlayeredframeworkforqualityadaptationwherethelowerlayersaremoreimpor-tantthanthehigherlayers.

Missingpacketsareretransmittedonlyifthereissuffi-cienttimeforretransmissionbeforeplayout.Withalayeredcodec,retransmissionofpacketsfromlayerhaveprior-ityoverbothnewpacketsfromlayerandoverallpacketsfromlayer.Thisisbecauseimmediatedataismoreimportantthanfuturedata,andthelowerlayersaremoreimportantforperceivedquality.

4.AnArchitecture

Inthissection,wecomposeourdesignchoicesintoacoherentend-to-endarchitectureandexplaintheinteractionamongdifferentcomponents.Figure1depictsthearchitec-ture.Thethreekeycomponentsarelabeledasrateadapta-tion,qualityadaptationanderrorcontrol.

End-to-endcongestioncontrolisperformedbytherateadaptation(RA)andackermodulesattheserverandclientrespectively.TheRAmodulecontinuouslymonitorstheconnectionandregulatestheserver’stransmissionratebycontrollingtheinter-packetgaps.Theackermoduleac-knowledgeseachpacket,providingend-to-endfeedbackformonitoringtheconnection.Theackermayaddsomere-dundancytotheACKstreamtoincreaserobustnessagainstACKloss.Moreover,eachACKpacketcarriesthemostre-centplayouttimebacktotheserver.Thisallowstheservertoestimatetheclientbufferoccupancyandperformqualityadaptationanderrorcontrolmoreeffectively.

Thequalityofthetransmittedstreamisadjustedbythequalityadaptation(QA)moduleattheserver.Thismoduleperiodicallyobtainsinformationabouttheavailableband-widthandthemostrecentplayouttimefromtheRAmod-ule.Combiningthisinformationwiththeaverageretrans-missionrateprovidedbytheerrorcontrolmodule,theQAmoduleadjuststhequalityofthetransmittedstreambyaddingordroppinglayersaccordingly.

Errorcontrolisperformedbytheerrorcontrol(EC)

4

moduleattheserver.Itreceivesinformationaboutavailablebandwidth,lossrateandrecentplayouttimefromtheRAmodule.Basedonthisinformation,iteitherflushespacketsfromtheserver’sbuffermanagerthatwereacknowledgedortheirplayouttimehavepassed,orschedulesretransmissionofalostpacket.TheECmodulecanselectivelyretransmitthosepacketsthathavehighprioritysuchaslossesfromthebaselayer.

SincebothqualityadaptationandretransmissionmustbeperformedwithintheratespecifiedbytheRAmodule,theECandQAmodulesneedtointeractcloselytosharetheavailablebandwidtheffectively.Thegoalistomaximizethequality(takingintoaccountpacketlossesofthefinalplayed-outstream)fortheavailablebandwidthwhilemini-mizinganyvariationsinquality.Ingeneral,retransmissionhasahigherprioritythanaddinganewlayerwheneverextrabandwidthisavailable.TheseinteractionsamongtheRA,QAandECmodulesareshownaspartofthecontrolpathinfigure1withthickerarrows.

Thedatapathwhichisfollowedbytheactualmultimediadata,isspecifiedseparatelywiththinnerarrows.Theservermaintainsanarchiveofstreamsinlocalmassstorage.Arequestedstreamispre-fetchedanddividedintopacketsbytheserverbuffermanagerjustpriortothedeparturetimeofeachpacket.Theresolution(i.e.numberoflayers)ofthepre-fetchedstreamiscontrolledbytheQAmodule.More-over,theQAandECmodulescooperativelyarrangetheor-derofpacketsforupcomingtransmission.Insummary,theRAmoduleregulatesthetransmissionrateandQAandECmodulescontrolthecontentofeachpacket.Theclient’sbuffermanagerreceivesthepacketsandrebuildsthelayeredencodedstreambasedontheplayouttimeofeachpacketbeforetheyarefedintothedecoder.Theplayouttimeofthebaselayerisusedasreferenceforlayerreorganization.Thebuffereddataattheclientsideisusuallykeptinmem-ory,butiftheclientdoesnothaveenoughbufferspace,thedatacouldbetemporarilystoredonadiskbeforeitissenttothedecoder

5.GeneralizingtheArchitecture

Weoutlinedasamplearchitectureforavideoplaybackserveranditsclienttodescribetheinteractionsamongdif-ferentcomponentsintheprevioussection.ThiscanbeviewedasagenericarchitectureforaclassofInternetvideoplaybackapplications.Theselectedmechanismswede-scribedforeachcomponentcanbereplacedbyothersfromthecorrespondingdesignspaceaslongastheyareinhar-monywithothercomponents.Forexample,onecouldde-ployanothertechniquesuchasFECforerrorcontrolonthebaselayer.Suchadesignchoicewouldaffectthebuffermanagementschemeattheserverandclientside,andwouldchangetheinteractionbetweenQAandECmodulessince

Internet ErrorControl Rate QualityAdaptation AdaptationTransmission Buffer AckerPlayout BufferDecoderReceiver Server Buffer Manager Buffer ManagerArchiveServerStorageClientControl PathFigure1.End-to-endarchitectureforplaybackstreamingapplicationsintheInternet

thereisnoneedtoleaveaportionoftheavailablebandwidthforretransmission.Insteadthebaselayerrequiresahigherbandwidth.AnotherexamplewouldbetoreplaceRAPwithacongestioncontrolmechanismbasedonmodelingTCP’slong-termthroughput.Thisimpliesthatqualityadaptationmustbetunedbasedontherateadaptationalgorithmofthenewcongestioncontrolmechanism.Itisgenerallymoreeffectivetodesignaqualityadaptationmechanismthatiscustomizedtothedesignchoicesfortheothercomponentsofthearchitecture.Forexample,knowingtherateadapta-tionalgorithmallowsustodeviseamoreoptimalqualityadaptationmechanism.

Akeypropertyofthisarchitectureistoseparatedifferentfunctionalitiesandassigneachofthemtoadifferentcom-ponent.Giventhisgenericarchitecture,thenaturalstepsfordesigninganend-to-endschemeforvideoplaybackappli-cationsarethefollowing:

1.SelectaTCP-friendlycongestioncontrolscheme.2.Selectanerrorcontrolschemethatsatisfiestheap-plicationrequirementgiventheexpectedormeasuredcharacteristicsofthechannel.3.Designaneffectivequalityadaptationmechanismandcustomizeitsuchthatitmaximizestheperceptualqualityofthedeliveredvideoforagivenencoding,rateadaptationalgorithmandthechoiceoferrorcon-trolmechanism.Congestioncontrolisanetworkspecificissueandithasbeenextensivelystudied.Howeverworkoncongestioncon-trolforstreamingapplicationsismorelimited.Errorcon-trolisawellunderstoodissueandonecanpluginoneofthewellknownalgorithmsfromthedesignspacethatsuites

5

theparticularapplication.Theremainingchallengeistode-signapplicationspecificqualityadaptationmechanismsthatreconciletheconstant-bitrate(orcontent-drivenvariablebit-rate)natureofvideoapplicationswiththecongestion-drivenvariablebandwidthchannel.Whiledoingthis,itmustinteractappropriatelywiththeerrorcontrolmecha-nismtowardthegoalofmaximizingtheperceptualquality.Webelievethatqualityadaptationisakeycomponentofthearchitecturethatrequiresmoreinvestigation.

6.ConclusionandFutureWork

ThispaperaimedtoprovidearchitecturalinsightsintothedesignofInternetvideoplaybackapplications.Towardthatgoal,wejustifiedtheneedforthreecrucialcomponents:(1)End-to-endcongestioncontrol,(2)Qualityadaptation,and(3)Errorcontrol.Webelievethatthemajorityofcur-rentInternetvideoplaybackapplicationsaremissingoneormoreofthesecomponents.Giventherapidincreaseinde-ploymentoftheseapplicationsandthesevereconsequencesofignoringtheseissues,itisimportanttounderstandtheseaspectsandapplythem.

Welimitedthedesignspaceforeachofthesecompo-nentsbasedonrequirementsthatareimposedeitherbyap-plicationsorbythenetworkandindicatethenaturalchoicesforeachone.Ourmaincontributionisincombiningthesecomponentsintoacoherentarchitectureanddescribingtheinteractionsamongthem.Aswellasdescribingpossiblespecificmechanismsforeachcomponent,weattempttogeneralizethearchitecturebyprovidingguidelinesonde-signchoiceforeachcomponentfromitsowndesignspace,andhighlighttheimplicationsontherestofthearchitecture.WepresentedtheideaoflayeredtransmissionforqualityadaptationwithintheAIMDpatternfortransmissionrate

andarguethatqualityadaptationisthemainchallengingopenissueforsucharchitectures.

Aspartofourfuturework,weplantostudyfurtherthequalityadaptationproblemtofindanearoptimalsolutionforaddanddropschemeswithdifferentcongestioncon-trolschemes.WewillvalidateouraddanddropschemealongwiththeRAPprotocolthroughsimulations.Wearealsoworkingonaprototypewhereweintegrateallthesepiecesandevaluatethem,firstinacontrolledphysicalen-vironmentsuchasCAIRN[14]andsubsequentlyovertheInternet.SincewehavealreadyevaluatedTCP-friendlinessoftheRAPprotocol,weonlyneedtoexaminetheaddanddropschemebasedonthesmoothnessandoptimalityofthedeliveredvideoquality.Finally,weplantoextendthisar-chitecturetoamulti-clientscenario,wheretheserverplaysbackavideostreamforagroupofclientssimultaneouslyusingmulticast.

7.Acknowledgments

WewouldliketothankTedFaber,JohnHeidemann,Al-lisonMankin,AhmedHelmy,ArtMenaandNirupamaBu-lusufortheirthoughtfulcommentsondraftsofthispaper.

References

[1]D.Black,S.Blake,M.Carlson,E.Davies,Z.Wang,and

W.Weiss.Anarchitecturefordifferentiatedservices.Inter-netdraft,Oct.1998.

[2]J.BolotandT.Turletti.Aratecontrolmechanismforpacket

videointheinternet.Proc.IEEEINFOCOM,pages1216–1223,June1994.http://www.tns.lcs.mit.edu/˜turletti/.

[3]J.-C.BolotandA.V.Garcia.ThecaseforFEC-basederror

controlforpacketaudiointheinternet.ToapearinACMMultimediaSystems.

[4]S.Cen,C.Pu,andJ.Walpole.Flowandcongestioncon-trolforinternetstreamingapplications.Proc.MultimediaComputingandNetworking,Jan.1998.

[5]D.ChiuandR.Jain.Analysisoftheincreaseanddecrease

algorithmforcongestionavoidanceincomputernetworks.JournalofComputerNetworksandISDN,17(1):1–14,June19.

[6]K.Claffy,G.Miller,andK.Thompson.Thenatureofthe

beast:Recenttrafficmeasurementsfromaninternetback-bon.Proc.INET,InternetSociety,Dec.1998.

[7]S.FloydandK.Fall.Promotingtheuseofend-to-endcon-gestioncontrolintheinternet.Undersubmission,Feb.1998.http://www-nrg.ee.lbl.gov/floyd/papers.html/end2end-paper.html.

[8]M.HandleyandS.Floyd.TCP-friendlycongestioncontrol.

Workinprogress.

[9]M.Inc.Netshowservice,streamingmediaforbusiness.

http://www.microsoft.com/NTServer/Basics/NetShowServices.[10]S.JacobsandA.Eleftheriadis.Real-timedynamicrateshap-ingandcontrolforinternetvideoapplications.WorkshoponMultimediaSignalProcessing,pages23–25,June1997.

6

[11]V.Jacobson.Congestionavoidanceandcontrol.InACM

SIGCOMM,pages314–329.ACM,Aug.1988.

[12]V.JacobsonandS.McCanne.vic:aflexibleframeworkfor

packetvideo.Proc.ofACMMultimedia,Nov.1995.

[13]J.-Y.Lee,T.-H.Kim,,andS.-J.Ko.Motionpredictionbased

ontemporallayeringforlayeredvideocoding.Proc.ITC-CSCC,1:245–248,July1998.

[14]C.Leffehocz,B.Lyles,S.Shenker,andL.Zhang.Con-gestioncontrolforbest-effortservice:whyweneedanewparadigm.IEEENetwork,10(1),January1996.

[15]A.Mankin.Collaborativeadvancedinteragencyresearch

network.SlidePresentation,Feb.1998.

[16]S.McCanne.Scalablecompressionandtransmissionofin-ternetmulticastvideo.Ph.D.thesis,UniversityofCaliforniaBerkeley,UCB/CSD-96-928,Dec.1996.

[17]S.McCanneandM.Vetterli.Jointsource/channelcoding

formulticastpacketvideo.Proc.IEEEInternationalCon-ferenceonImageProcessing,pages776–785,Oct.1995.[18]R.Networks.Httpversusrealaudioclient-serverstreaming.

http://www.realaudio.com/help/content/http-vs-ra.html.[19]A.OrtegaandM.Khansari.Ratecontrolforvideocoding

overvariablebitratechannelswithapplicationstowirelesstransmission.Proc.ofthe2ndIEEEInternationalConfer-enceonImageProcessing),Oct.1995.

[20]J.Padhye,J.Kurose,D.Towsley,andR.Koodli.TCP-friendlyrateadjustmentprotocolforcontinuousmediaflowsoverbesteffortnetworks.TechnicalReport98-47,UMASSCMPSCI,Oct.1998.

[21]C.PapadopoulosandG.M.Parulkar.Retransmission-based

errorcontrolforcontinuousmediaapplications.InProc.NOSSDAV,Apr.1995.

[22]C.Perkins.Optionsforrepairofstreamingmedia.Internet

Draft,Mar.1998.

[23]R.Ramjee,J.F.Kurose,D.Towsley,and.H.Schulzrinne.

Adaptiveplayoutmechanismsforpacketizedaudioapplica-tionsinwide-areanetworks.Proc.IEEEINFOCOM,1994.[24]R.Rejaie,M.Handley,andD.Estrin.RAP:Anend-to-endrate-basedcongestioncontrolmechanismforrealtimestreamsintheinternet.InProc.IEEEINFOCOM,1999.[25]R.Rejaie,M.Handley,H.Yu,andD.Estrin.Proxycaching

mechanismformultimediaplaybackstreamsintheinternet.Proc.ofthe4thInternationalWebCachingWorkshop,Mar.1999.

[26]D.SisalemandH.Schulzrinne.Theloss-delaybasedad-justmentalgorithm:ATCP-friendlyadaptationscheme.InProc.NOSSDAV,1998.

[27]W.TanandA.Zakhor.Errorresilientpacketvideoforthe

internet.Proc.oftheIEEEInternationalConferenceonIm-ageProcessing),Oct.1998.[28]T.Turletti.TheINRIAvideoconferencingsystem

(IVS).ConneXions-TheInteroperabilityReportJournal,8(10):20–24,Oct.94.

[29]M.VishwanathandP.Chou.Anefficientalgorithmforhi-erarchicalcompressionofvideo.Proc.oftheIEEEInterna-tionalConferenceofImageProcessing,Nov.1994.

[30]L.Zhang,S.Deering,D.Estrin,S.Shenker,andD.Zappala.

RSVP:anewresourcereservationprotocol.IEEENetwork,7:8–18,Sept.1993.