Management
RichardWestandKarstenSchwanCollegeofComputingGeorgiaInstituteofTechnology
Atlanta,GA30332
Abstract
Manycomplexdistributedapplicationsrequirequalityofservice(QoS)guaranteesontheend-to-endtransferofinformationacrossadistributedsystem.Amajorproblemfacedbyanysystem,orinfrastructure,providingQoSguaranteestosuchapplicationsisthatresourcerequirementsandavailabilitymaychangeatrun-time.Con-sequently,adaptiveresource(and,hence,service)managementmechanismsarerequiredtoguaranteequalityofservicetotheseapplications.
Thispaperdescribesdifferentmethodsofadaptivequalityofservicemanagement,implementedwiththeevent-basedmechanismsofferedbytheDionisysqualityofserviceinfrastructure.Dionisysallowsapplicationstoinflu-ence:(1)howserviceshouldbeadaptedtomaintainrequiredquality,(2)whensuchadaptationsshouldoccur,and(3)wheretheseadaptationsshouldbeperformed.InDionisys,servicemanagersexecuteapplication-specificfunctionstomonitorandadaptservice(and,hence,resourceusageandallocation),inordertomeetthequalityofservicerequirementsofadaptableapplications.Thisapproachallowsservicemanagerstoprovideserviceinamannerspecifictotheneedsofindividualapplications.Moreover,applicationscanmonitorandpin-pointre-sourcebottlenecks,adapttheirrequirementsforheavily-demandedresources,oradapttodifferentrequirementsofalternativeresources,inordertoimproveormaintaintheiroverallqualityofservice.Likewise,servicemanagerscancooperatewithotherservicemanagersand,byusingknowledgeofapplication-specificresourcerequirementsandadaptationcapabilities,eachservicemanagercanmakebetterdecisionsaboutresourceallocation.Usingareal-timeclient-serverapplication,builtontopofDionisys,wecomparealternativestrategiesforadaptingandcoordinatingCPUandnetworkservices.Inthisfashion,wedemonstratetheimportanceofflexibilityinqualityofservicemanagement.
1.Introduction
Complexdistributedapplications,includinggroupware[14],virtualenvironments(e.g.,DIVE[5,18]),dis-tributedgames[29],multimediavideoandaudio,anddistributedinteractivesimulations(DIS)[24]requirequalityofservice(QoS)guaranteesontheend-to-endtransferofinformationacrossadistributedsystem.Amajorprob-lemfacedbyanysystem,orinfrastructure,providingqualityofserviceguaranteestosuchapplicationsisthatresourcerequirementsandavailabilitymaychangeatrun-time.Forexample,anapplicationmayrequiremoreorlessCPUcyclestoidentifyatargetobjectinagraphicalimage,dependingonthecontentofthatimage.Likewise,resourceavailabilitymaychangeduetoadynamicallychangingnumberofapplicationtaskssharingafinitesetofcommonresources.Consequently,adaptiveresource(and,hence,service)managementisrequiredtoguaranteeand,possibly,maximizequalityofservicetocomplexapplications.Furthermore,itisimportantthatadaptiveresourcemanagementmechanismsbuiltwithinasystemorinfrastructureareawareofthespecificneedsofindi-vidualapplications.
Manyresearchgroupshaveproposeddifferentarchitecturesandmiddleware[4,13,27,20,2,26],toprovideruntimequalityofserviceguaranteesoninformationexchangedbetweenhostsinadistributedenvironment.How-ever,theDionisysQoSinfrastructure,thatwepropose,supportsapplication-specificextensionsforqualityofservicemanagement,byallowingapplicationstocontrol:(1)howserviceshouldbeadaptedtomaintainrequiredlevelsofquality,(2)whensuchadaptationsshouldoccur,and(3)wheretheseadaptationsshouldbeperformed.Dionisyssupportsper-applicationqualitymanagement,whichisparticularlyimportantforlarge-scale,complexapplications,whereservicequalitymaydependonmultipleservicetypes,requiringthatoneservicetypebeadaptedtocompensatefortoomuchortoolittleserviceofanothertype.Forexample,consideranapplicationthatrequiresbothCPUandnetworkservicestogenerateandtransferinformationtoaclientonaremotehost.Inthiscase,tocompensateforinsufficientbandwidth,theapplicationcanadaptbyusingmoreCPUcyclestoencode(andcompress)theinformationbeforeitistransmitted.Incontrast,ifapplicationshavenocontroloverwhichservicesareadapted,thesystemwouldhavetodetermineanacceptablequalityforeachofthe
active
applications,byprovidingappropriatelevelsofserviceineachof
possibleservicetypes.Thedifficultnature
ofruntimesolutionsforsuchaqualitymaximizationproblemisexacerbatedbythefactthatapplications'servicerequirementsaswellasthesystem'sresourceavailabilityvarydynamically.
TheDionisysapproachtoqualitymanagement,describedinthepreviousparagraph,istospecializethefashioninwhichadaptationsareperformedforeachapplication.Thisisachievedbyallowingeachapplicationtoshare,withspecificservicemanagers,theinformationnecessaryforruntimeserviceadaptation.Additionally,theap-plicationmayadaptitsownbehavior,inconjunctionwiththeserviceadaptationsbeingperformedonitsbehalf.Suchspecialized,jointqualitymanagementusesanevent-basedmechanismofferedbytheDionisysqualityofserviceinfrastructure.Aspartofthismechanism,applicationsspecify:(1)monitorfunctionsthatarewrittento
captureservicequalityatspecifiedtimesandgenerateeventsifserviceadaptationisrequired,and(2)handlerfunctions,thatareexecutedinresponsetoadaptationeventsraisedbyservicemanagers.Asaresult,applica-tionscontrolwhichsystemserviceisadaptedbyspecifyingwhichservicemanagerexecutesamonitorandwhichservicemanagerexecutesitscorrespondingcontrolhandler.Towardthisend,an`eventchannel'isestablishedbetweenamonitorinoneservicemanageranditscorrespondingcontrolhandler,whichisexecutedbythesame,orbyanotherservicemanager.Inthisfashion,servicemanagerscanprovideservicetoapplicationsinamannerspecifictotheirindividualneeds,andapplicationscanmonitorandpin-pointresourcebottlenecks,adapttheirrequirementsforheavily-demandedresources,oradapttodifferentrequirementsofalternativeresources,inordertoimproveormaintaintheirqualityofservice.Insummary:
Aneventspecifiesthesemanticinformationneededbyahandlertodeterminehowtoadaptserviceinordertomaintainorimproveapplication-levelquality.Forthisreason,eventsintheDionisysinfrastructurearetermedqualityevents;
Monitorfunctionsexecuteatratesspecifiedbyapplicationsandgenerateeventswhenserviceadaptationisrequired;
Applicationsspecifywheremonitorsandhandlersshouldexecute(i.e.,withinwhichservicemanagers),inordertoadaptserviceallocationand/orrequirements.
Contributions.Inthispaper,wecompareandcontrastseveraladaptationstrategiesimplementedwithqualityevents,therebydemonstratingtheflexibilityoftheDionisysqualityofserviceinfrastructure.Specifically,weshowthatforcertainapplications,`out-of-band'adaptationsareinadequate,therebynecessitatingtheuseofqualityeventstoimplement`in-band'adaptations.In-bandadaptationsoccurasapplication-leveldataisbeingprocessedand/ortransferred,alongthelogicalpathofresourcesleadingtothedestination.Bycontrast,typicalout-of-bandadaptationsarenotenacteduntilsubsequentdataistransferredalongthesamelogicalpath.Finally,weshowthatbycoordinatingserviceadaptationsbetweenanumberofservicemanagers,applicationscanachievehighqualitiesofserviceinanefficientmanner.
ThenextsectiondescribestheDionisysapproachtoqualitymanagementinmoredetail.Then,Section3describesissuesandtradeoffsintheimplementationofdifferentadaptationstrategies.Section4presentsanexperimentalevaluationofDionisys,byusingavideoserverapplicationmentionedinSection2.1tocompareandcontrastdifferentadaptationstrategies.RelatedworkisdescribedinSection5,whileconclusionsaredescribedinSection6.
2.TheDionisysApproachtoConfigurableQualityManagement
TheDionisysQoSinfrastructure(seeFigure1)comprisesseveralkeycomponentstosupportper-applicationconfigurablequalityofservicemanagement:
SOURCE HOST
ProcessProcessEvents for App.processesCPU SMMonitorsHandlersScheduler PacketMonitorsScheduling,Policing etcHandlersNetwork SMNetworkDESTINATION HOST
App. LevelSystem LevelMonitorsHandlersSchedulerMonitorsHandlers BufferMgmt. etcMonitorsHandlersApplication Specific PolicyProcessProcessApplicationMonitorsApplicationMonitorsApplicationMonitors Specific Specific Specific PolicyHandlers PolicyHandlers PolicyHandlersApp-Specific SMEvent channelsQoS attribute pathData pathFigure1.DionisysQoSInfrastructure
ServiceManagers(SMs).Servicemanagersexecuteapplication-specificmonitorandhandlerfunctions,aswellasservicepoliciesthatcontroltheallocationofresourcestocompetingapplicationprocesses.
Monitors.Monitorsareapplication-specificfunctionsthattriggerpotentialserviceadaptations,iftheactualqualityofagivenservicetypeisunacceptable,orlessthandesired.
Handlers.Handlersareapplication-specificfunctionsthatinfluencehowserviceand,hence,theallocationofresourcesamongcompetingapplicationsisadapted.
QualityEvents.Eventsaregeneratedbytheexecutionofamonitorfunctionwhenoneormoreservicetypesarerequiredtobeadapted.Theattributesassociatedwithaneventareusedtodecidetheextenttowhichserviceshouldbeadaptedinthetargetservicemanager.Forthisreason,eventsandtheirattributesarecollectivelynamed`qualityevents'.
EventChannels.Eventchannelsallowsqualityeventstobecommunicatedbetweenmonitorandhandlerroutinesthatexecuteinthecontextofdifferentservicemanagers.Notethateventscanalsobedeliveredtoapplicationprocesses,thatcanadapttheirownbehavior.
Figure1depictsanumberofapplication-specificservicemanagers,complementedbytwomore`generic'servicemanagersthatcontrolhowCPUandnetworkservicesaredeliveredtoapplicationprocesses.Forexample,forthevideoserverdescribedlaterinthepaper,anapplication-specificservicemanagercouldcontrolframeresolution,whiletheCPUandnetworkservicemanagerscontroltherateatwhichframesaregeneratedandtransmittedacrossanetwork,respectively.Qualityevents,transportedviaeventchannelsbetweentheseservicemanagers,causeframeresolutionandratetobeadaptedinkeepingwiththevideoserver'squalityofservicerequirements.
DionisysImplementation.EachservicemanagerusedinDionisysmaintainstwoqueues:onequeueforapplication-specificmonitorfunctionsandanotherforapplication-specifichandlerfunctions.Themonitorspasseventstohan-dlerswhenanapplicationrequiresitsservicetobeadapted.Eventsmayalsobeshippedbacktotheapplicationsthemselvestobehandledinthecorrespondingapplication'saddressspace.Aspartofaservicemanager'sjob,itmustexecuteitsmonitorsandhandlersatappropriatetimes:monitorsareexecutedatapplication-specifictimesandhandlersareexecutedinresponsetoeventsgeneratedbymonitors.Ingeneral,aservicemanagerrunswhenitmusteitherexecuteitsservicepolicy,executeoneormoremonitors,executeoneormorehandlersinresponsetopendingevents,orprocessrequestsfromapplicationstocreateneweventchannels.
Monitor Functions
M(1)M(2)M(m1)Handler Functions
H(1)H(2)H(h1)SM 1
. . .. . .SM 2
M(1)M(2). . .M(m2)H(1)H(2). . .H(h2)Event Channel
Figure2.Exampleeventchannelsinvolvingtwoservicemanagers,
and
,inDionisys.
Figure2showsanexampleofseveraleventchannelsbetweentwoservicemanagers,servicemanager,
and
.Each
,maintainsanarrayofpointerstomonitorfunctions(
to
),andanarrayof
pointerstohandlerfunctions(to
).Eachservicemanagerexecutesatmostonemonitorfunctionand
onehandlerfunctionperapplicationprocess.Aneventchannelbindsoneormorehandlerfunctionstoasinglemonitor,whichgeneratesapplication-specificqualityevents.Notethatthereisatmostonehandlerforaneventchannelinanyoneservicemanager,buttherecanbemultiplehandlers,spanningdifferentservicemanagers,connectedtothesameeventchannel.Forexample,Figure2showstwohandlersconnectedviathesameeventchanneltomonitor,
,inservicemanager,
.
Inthecurrent(Solaris-based)implementationofDionisys,servicemanagersonthesamehostallexecuteaskernel-levelthreads,withinthesameaddressspace.Applicationprocessesaccesstheseservicemanagersvialibrarycallsthatutilizeasharedmemoryapplication-programminginterface(API).TheDionisysAPIallowsapplicationstocreate,ordelete,application-specificservicemanagersand/oreventchannels,ortoexchangedatawithexistingservicemanagers1.Therationaleforthisimplementationistoemulatethewayinwhichoperatingsystemservicesareaccessedviasystemcallsfromapplicationprocesses.Furthermore,applicationscanspecializetheoperationofDionisysservicemanagers,orcreatenewservicemanagers,inthesamewaythatkernel-loadable
modulescanbedynamically-linkedintoan`extensible'operatingsystem2.Statedconcisely,whenanapplicationcreatesanapplication-specificservicemanager(whichexecutesapplication-specificpolicies),theservicemanagerfunctionalityiscompiledintoasharedobjectanddynamicallylinkedintotheDionisyssystem-leveladdressspace.Fortheuser-levelrealizationofDionisysusedinthispaper,thisaddressspaceisthatofadaemonprocessrunningallDionisysservicemanagers.Forthekernel-levelrealizationofDionisysnowbeingdevelopedbyourgroup,thisaddressspaceisthatofthe(Linux)operatingsystemkernel.Inthisfashion,wecanincorporateapplication-specificservicemanagersintoDionisys,supportingconfigurableprotocolsandotherfunctionsapplicableto,andprovidedby,eachapplication.Finally,whenrunningDionisysacrossadistributedsystem,eachhosthasitsownDionisysdaemonprocess.Asimplenameserveruniquelyidentifieseachservicemanagerexecutingwithineachandeverydaemonprocess.Socketsarethenusedtocommunicateapplicationdata,QoSattributesandeventsbetweentheseprocessesondifferenthosts.
UsingDionisys.Applicationsspecifythefunctionalitytomonitorservicequalityatpredeterminedtimes.Typi-cally,monitorfunctionsareexecutedperiodically,ataratedeterminedbytheapplication3.Consequently,monitorsinfluencewhenadaptationsoccur.Dependingontheactualmonitorfunctionexecutedbyaspecificserviceman-ager,aneventmayberaisedtoaltertheserviceprovidedbythesameoranotherservicemanager.Aneventistypicallyraisedwhentheactual(monitored)andrequiredservicelevelsdifferbyanamountthatcausesanappli-cationtojeopardizeitsQoSrequirements.Alternatively,amonitormightgenerateaneventifitispossiblethatbetterqualityofservicecanbeachievedbyadaptingoneormoreservicetypes.Eventsarepassedbetweenorwithinservicemanagersvia`eventchannels'.Howaneventishandledactuallydependsonthehandlerfunctionthatisspecifiedbytheapplication,andexecutedbythetargetservicemanager.Furthermore,applicationshavetheabilitytocontrolwheremonitorandhandlerfunctionsareexecuted.Thatis,eachapplicationusingtheDion-isysQoSinfrastructurehastheabilitytospecifytheservicemanagersresponsibleforexecutingitsmonitorandhandlersfunctions.Insummary,the`system'establishesan`eventchannel'betweenamonitorinoneservicemanageranditscorrespondinghandler,whichisexecutedbythesame,oranotherservicemanager.Serviceman-agersdynamically-linkwithsharedobjectscontainingthemonitoringandhandlingfunctionsatruntime.Observethattheissuesofprotectionassociatedwithdynamicallylinkingapplication-specificmonitoring,handlingandservicemanagerfunctionalityintoDionisyshavebeenomitted.Thisworkfocusesmoreontheissuesofprovidingaframeworktosupportapplication-specificextensionsforqualityofservicemanagement.
2.1.AnAdaptableClient-ServerApplication
Figure3showsanadaptableclient-serverapplication,usingtheDionisysQoSinfrastructure.Serverprocessessenddatatoclientprocessesononeormoreremotehosts.TheCPUservicemanagerallocatesCPUcyclesto
SERVER HOSTProcessProcessApplication LevelSystem LevelMonitorsHandlersSchedulerMonitors PacketScheduling, Rate Ctrl.HandlersNetwork SMNetworkREMOTE HOSTClient ProcessesProcessEvent channelsProcessQoS attribute pathData path Memory Manager RingQoS attrsBuffersQoS attrsCPU SMFigure3.Exampleadaptableclient-serverapplication,witheventchannelsbetweenCPUandnetworkservicemanagersontheserverhost.Serverprocessessenddatatoclientprocessesonaremotehost.
applicationprocessesbasedonaschedulingpolicythatisconfiguredwhentheservicemanagerisinitialized.Thenetworkmanagermaintainsabufferforqueueingpacketsofdatareadyfortransmissionacrossanetwork.ShowninFigure3isamemorymanager,responsibleforallocatingspacetoapplicationdata,andQoSattributesassociatedwiththatdata.InDionisys,thememorymanagerisusedmerelytomanagesharedmemory,sothatapplicationprocessesandservicemanagerthreadscancommunicateandexchangeinformation.
AVideo-ServerExample.ConsiderthecasewhereFigure3representsavideo-server.Serverprocessescouldbevideostreamingprocesses,thatgeneratesequencesofvideoframes.Thesevideoframesaresplitintopacketsandplacedinringbuffersinsharedmemory,withoneringbufferpervideostream.AssociatedwitheachstreamareQoSattributes,thatspecifyparameterssuchasthroughputandframeloss-rate.Ifaringbufferisbackloggedwithtoomanypackets,thenetworkservicemanagercanbeconfiguredtodropqueuedpacketsordiscardincomingvideoframes.Furthermore,thenetworkmanagermultiplexespacketsovertheoutgoingnetworklink,usingoneofseveralpacketschedulingpolicies,suchasbest-effort/FCFS,staticpriority(SP),earliest-deadlinefirst(EDF),start-timefair-queueing(SFQ)[21]anddynamicwindow-constrained(DWCS)[28]scheduling.Oncethevideoframeshavebeentransmittedandreceivedatthedestination,clientprocessesdecodeandplaybacktheseframes.WenowdiscussseveraldifferentadaptationstrategiesthatcanbeimplementedinDionisys,tocontroltheallo-cationofresourcesinapplicationsliketheonejustillustrated.InourcooperationwithHoneywellCorporation,wehavealsodevelopedsimilaradaptationstrategiesandexperimentedwiththemonanAutomaticTargetRecognition(ATR)application.Consequently,theadaptationstrategiesdescribedintheremainderofthispaperalsoapplytootherapplications,andnotjusttheonedescribedinthissection.
3.AdaptationConfigurations
Monitors(b) Upstream AdaptationHandlers(c)CPU Service ManagerNetwork Service ManagerMonitorsHandlers(c) Intra-SM Adaptation(a) Downstream AdaptationFigure4.Adaptationscenarios:(a)downstreamadaptation,(b)upstreamadaptation,and(c)intra-SMadaptation.Observethatinbothdownstreamandupstreamadaptation,eventsarealsodeliveredtohandlerswithinthesameservicemanagerfromwheretheyoriginated.
Figure4showsthethreeadaptationconfigurationsconsideredinthispaper.Forsimplicitywefocusonadap-tationsbetweenCPUandnetworkservicemanagers,butwhatfollowsappliestoanycombinationofservicemanagers:
DownstreamAdaptation–Inthisconfiguration,eventsaredeliveredfrommonitorsintheCPUservicemanagertohandlerswithinboththeCPUandnetworkservicemanagers.Intuitively,eventsfromtheCPUservicemanagertothenetworkservicemanagerfollowtheforward-goingpathofapplicationdata,asitisgeneratedandthentransmitted.Observethat,inordertogeneratedata,applicationprocessesmustacquireCPUcyclesfromtheCPUservicemanager.Onlyafterdatahasbeengenerated,canitbeallocatednetworkbandwidthfortransmissionbythenetworkservicemanager.Consequently,itispossiblefordownstreameventstobedeliveredinsynchronyand,hence,`in-band'withdataflowingthroughthelogicalpathofresources.
UpstreamAdaptation–Inthisconfiguration,eventsaredeliveredfrommonitorsinthenetworkservicemanagertohandlerswithinboththenetworkandCPUservicemanagers.Theterm`upstreamadaptation'isusedtoidentifythesituationwhereeventsaredeliveredinadirectionopposingthelogicalflowofap-plicationdata.ThisisthecaseforeventsfromthenetworkservicemanagertotheCPUservicemanager.Upstreamadaptationrequireseventstobedelivered`out-of-band'withtheflowofdata.
Intra-SMAdaptation–Inthisconfiguration,eventsaredeliveredfrommonitorstohandlerswithinthecorrespondingservicemanager.Thisconfigurationdoesnotalloweventstobeexchangedbetweenservicemanagers,sothereisnoexplicitcoordinationofmultipleservicetypes.
Observethat`upstreamadaptation'isnottobeconfusedwith`feedbackcontrol',whichisatermcommonlyusedinclassicalclosed-loopcontroltheory.Astutereadersmaynoticethatpassingeventsbetweenmonitorsandhandlersissimilartoaclosed-loopfeedbackcontrolmechanism,inwhichthehandlersarelikecontrolactuators.Therefore,allthreeadaptationconfigurationscanbethoughtofasusingfeedbackcontrolloops,constructedusing`eventchannels'carrying`qualityevents'.
Wewillnowshowacomparisonofdownstreamversusupstreamadaptationstrategies,toillustratetheirperfor-mancetradeoffs.Asaconsequenceoftheseperformancetradeoffs,itisimportantforaflexibleQoSinfrastructuretosupportdifferentadaptationconfigurations.
11X1XXX1XXX10123456789101112time, t
EEFigure5.ExampleCPUschedule.`1'indicatestheexecutionofprocess,ofaprocessotherthan
,`X'indicatestheexecution
,and`E'indicatesthegenerationofanevent.
AComparisonofDownstreamversusUpstreamAdaptation.Figure5showsanexampleCPUschedule.Thefollowingexampleshowsthetradeoffsbetweendownstreamandupstreamadaptations,ignoringanydelaysintransferringeventsbetweenservicemanagers.Asisthecasethroughoutthispaper,thisexampleassumeseventsaretransferredonlybetweenCPUandnetworkservicemanagers.Considerthesituationwhereeachunitoftimeaprocess
(indicatedby`1'inFigure5)executes,itgenerates
onepacketofinformation.Moreover,eachpacketthatisgeneratedhastobetransmittedbythenetworkservicemanagerimmediately,otherwiseitisconsideredlateandisdiscarded.Suppose,thenetworkservicemanagermustensurethatonepacketistransmittedeverythreetimeunits.Consequently,generateatleastonepacketeverythreetimeunits.Thatis,
requiresenoughCPUtimeto
needsatleastoneunitofCPUtimeeverythreetime
units,assumingtherearenooverheadsinschedulingandtransmittingpacketsthataregenerated.Atthenetworkservicemanager,thepacketsgeneratedby
haveacorrespondingloss-tolerance.Initially,thisloss-toleranceis
,indicatingthatatmosttwooutofapossiblethreepacketsgeneratedeverywindowofthreetimeunitscanbeDownstreamAdaptation.Considernow,thesituationinwhichtheCPUservicemanagerobservesthatattime,
discardedand,hence,lost.
,
hasexecutedforonetimeunitintheinterval
.At
,theCPUservicemanagerschedules
adifferentprocess(denotedby`X'inFigure5),whichisconsideredmoreimportantthanCPUservicemanagerdoesnotservice
.Furthermore,the
againintheinterval
.IftheCPUservicemanageruses
knowledgeofitsfutureschedulingdecisions,itcandecideat
togenerateaforward-goingevent,whichissent
tothenetworkservicemanager,totrytoguaranteethatthemostrecentpacketgeneratedbyotherwisetheloss-toleranceofrecentpacketgeneratedby
mustbetransmitted,
isviolated.Thatis,ifthenetworkservicemanagerdoesn'ttransmitthemost
,thennoneof'spacketswillbetransmittedintheinterval
.The
handlerfortheforward-goingevent,executedbythenetworkmanager,setstheloss-toleranceof
,inanattempttoguaranteethatnoneof
'spacketsto
'spacketsarediscardedinthenexttimeunit.Thisreductionin
loss-tolerancecanbeusedbythenetworkmanager'sservicepolicytoschedulegeneratesanothereventtotrytoguaranteethepacketjustgeneratedbyobservesthat,atfrom
'smostrecentpacketbefore
,downstreamadaptation
anyotherpackets,assumingnootherpacketsaremoreimportant.Observealso,at
istransmitted.
UpstreamAdaptation.Considerthealternativesituation,whereamonitorinthenetworkservicemanager,
,twotimeunitshavepassedinthecurrentwindowofthreetimeunits,andnopackets
havebeentransmitted.Theassumptionhereisthat,althoughapacketwasgeneratedat
,the
networkservicemanagerdidnottransmitHowever,atto
'spacket,becausesomeotherpacketwasconsideredmoreimportant.
,anupstreameventissentfromthenetworkservicemanagertotheCPUservicemanager.This
eventtriggersahandlerintheCPUservicemanager,totrytoensurethatCPUcyclesareimmediatelyallocated
,sothatitcangenerateonepacketbeforethecurrenttimewindowhasended.Theproblemhereisthatthe
networkservicemanagerisunawareoftheCPUservicemanager'sschedule,andConsequently,nonewpacketswillbegeneratedby
willnotbescheduledat
.
,andtheoriginalserviceconstraint,thatatleastonepacket
everythreetimeunitsistransmitted,willbeviolated.
Thepointofthisexampleistoshowthatupstreamadaptationcanperformworsethandownstreamadaptation,iftheallocationofresourcesbyaservicemanager,earlierinthelogicalpathalongwhichinformationflows,cannotbedetermined.Intheaboveexample,theCPUservicemanagerisearlierintheinformationpaththanthenetworkservicemanager,becausedatamustbegeneratedbeforeitistransmitted,andgenerationofdatarequiresCPUcycles.Furthermore,thenetworkservicemanagerdoesnothaveaccesstoCPUschedulinginformation,whichiswhyitcannotknowwhentogenerateanevent,ifsuchaneventisnecessarytoadaptserviceinthefuture.Conversely,downstreamadaptationcanperformworsethanupstreamadaptation,iftheallocationofresourcesbyaservicemanager,laterinthelogicalpathalongwhichinformationflows,cannotbedetermined.Intheaboveexample,theforward-goingeventtothenetworkservicemanager,thatsetstheloss-toleranceto
only
guarantees
'smostrecentpacketistransmittedifnootherpacketsaremoreimportant.IftheCPUservice
managerdoesnothaveaccesstopacketschedulinginformationinthenetworkservicemanager,thentheCPUservicemanagerdoesnotknowwheneventsshouldbegenerated,ifeventsarenecessarytoadaptserviceinthefuture.
Ingeneral,ifaservicemanager,manager,
,doesnothaveaccesstotheserviceinformationinanotherservice
,then
doesnotknowwhenaneventshouldbegenerated,ifaneventisnecessaryto
to
adapttheserviceof
inthefuture.Thisistrueevenifthedelayindeliveringaneventfrom
isknown,andtakenintoaccountby
whengeneratingtheevent.
Theaboveexampleillustratesasituationwherebothdownstreamandupstreamadaptationstrategiesareuseful.TheflexibilityoftheDionisysevent-basedadaptationmechanismallowsbothtypesofadaptationstrategiestobeimplemented,aswellasothers.Thenextsectionevaluatesseveraladaptationstrategiesusingasimplevideoserverapplication,liketheonedescribedinSection2.1.Moreover,theseadaptationstrategiesemphasizethedifferencesinservicequalitydependingonhowserviceadaptationandcoordinationisimplemented.Again,wefocusontheissueofadaptingandcoordinatingCPUandnetwork-levelservices,usingbothCPUandnetworkservicemanagers.
4.ExperimentalEvaluation
Weranaseriesofexperiments,usingSolaris2.6onadualPentiumPro180MHzPC,servingaclientmachineconnectedvia10Mbpsethernet,toshowtradeoffsindifferentserviceadaptationstrategies.Thesestrategiesdifferedinhow,whenandwhereserviceadaptationstookplace.AvideoserverwasconstructedasinSection2.1.Serverprocessesgeneratedvideoframes,whileclientprocessesdecodedandplayedbackframesarrivingfromthenetwork.TheCPUservicemanagerusedastaticprioritypreemptiveschedulingpolicy,toscheduleallapplicationprocesses(onepervideostream),whilethenetworkservicemanagerscheduledallpacketsofvideoframesfromtheheadsofsharedmemoryringbuffers(again,oneringbufferperstream),usingdynamicwindow-constrainedscheduling(DWCS)[28].SincethenetworkservicemanagerwasimplementedasaSolariskernelthread,intheDionisysdaemonprocess,thepacketschedulerdidnotaccesstheethernetdevicedirectly,butviasockets.Inthefirstsetofexperiments,1000MPEG-1I-frames4froma`StarWars'sequenceweregeneratedforthreedifferentstreams,
,
and
.TheQoSattributesassociatedwitheachstreamwereminimum,maximumand
targetframerates.TheQoSattributesfor
,
and
were
,
and
framespersecond(
),
respectively.AQoSviolationoccurredwhentheactualtransmissionratewasoutofthespecifiedrangeforthecorrespondingstream,atthetimeitwasmonitoredbythenetworkservicemanager.
InordertoscheduleallthreestreamstomeettheirQoSrequirements,theCPUschedulingprioritiesweredynamicallyadjusted.Moreover,prioritieswereadjustedinaccordancewiththenecessaryCPUcycles,ateachpointintime,toguaranteetherequiredgenerationrateand,ultimately,therequiredtransmissionrateofframesfromeachvideostream.
Intheseexperiments,thefollowingadaptationconfigurationswerecompared:
DownstreamAdaptation.TheCPUservicemanagermonitoredeachstream'sframegenerationrate:iftheactualgenerationratewasnotequaltothetargetrate,aneventwassenttotheCPUservicemanagerand(forwardto)thenetworkservicemanager.
UpstreamAdaptation.Thenetworkservicemanagermonitoredeachstream'sframetransmissionrate:ifactualtransmissionratewasnotequaltothetargetrate,aneventwassenttothenetworkservicemanagerand(backto)theCPUservicemanager.
Intra-SMAdaptation.BothCPUandnetworkservicemanagersindependentlymonitoredeachstream'sgenerationandtransmissionrates,respectively,andsenteventstothemselvesifastream'stargetratewasnotequaltoitsactualrate.
Inallcases,themonitorfunctionsranevery
milliseconds,toensurethatQoSstateinformationwassampled
fastenough.TheCPUservicemanagerexecutedthesamehandlerforeachstream.ThehandlerattemptedtoaltertheSolaris`RT'(real-time)priorityofthecorrespondingstream-generatorprocessbyanamountthatwasalinearfunctionofthedifferenceintargetandactualservicerates.Toensureonestreamwasnotundulyservicedatthecostofotherstreams,theCPUservicemanagerexecutedaguardfunction,whichrange-checkedpriorityassignments.RatecontrolintheCPUservicemanagerwastriggered,ifthehighest-priorityframe-generatorprocesshadanactualrategreaterthanthemaximumrequiredgenerationrate.ThisforcedtheCPUschedulertorunasanon-work-conservingscheduler.
Thenetworkservicemanagerranthesamehandlerfunctionforallthreestreams.ThehandlerfunctionadaptedDWCSschedulingparameterstoaltertheallocationofserviceinaspecificwindowoftime.Thatis,moreorlessconsecutivepacketsofvideoframesfromthesamestreamweretransmittedinagiventimeinterval.Ratecontrolinthenetworkservicemanagerwasactivatediftheactualrateofastreamexceededitsmaximumtransmissionrate.
250
Buffered Frames/Missed Deadlines200150100500
Downstream Adaptation (Target 10 fps)
Buffered Frames/Missed DeadlinesBuffered Frames
Cumulative Missed Deadlines
250200150100500
Upstream Adaptation (Target 10 fps)
Buffered Frames
Cumulative Missed Deadlines
Buffered Frames908070605040302010
0
20
406080Time (seconds)
100
120
00
20
406080Time (seconds)
100
120
Target 10 fps (Intra-SM Adaptation)
020
406080Time (seconds)
100120
Figure6.Bufferingofthe10fpsstream,
,with(a)downstream,(b)upstream,and(c)intra-SM
adaptation.Cumulativemisseddeadlinesarealsoshownfordownstreamandupstreamadaptations.
Buffering:Figure6showsupstreamadaptationhasgreatervarianceinbufferusage.Theresultsareshownfor
,butthesameobservationsapplytoallstreams,irrespectiveoftheirtargetrate.Downstreamandintra-SM
adaptationsshowsimilarbehavior:themaximumnumberofbackloggedframesforastreamandtheperiodsin
whichtheringbuffersareemptyislesswithbothdownstreamandintra-SMadaptations,thanwithupstreamadaptation.Observethatwithupstreamadaptation,thenetworkmonitorfunctionsraiseeventstoolate,torequestthegenerationofmoreframes.Thatis,controleventsaregeneratedwhennothingcanbedoneuntilfuturedataisgenerated.Bycontrast,downstreamadaptationcanleadtoadaptationchanges`in-band'withthecurrentdata,asittraversesthelogicalpathofresources,toitsdestination.
Otherresearchershaveproposedanadaptationstrategyforreal-ratescheduling[25],thatissimilartointra-SMadaptation.Inreal-ratescheduling,bufferfill-levelsaremonitored,asopposedtogenerationandtransmissionrates.Dependingonthefill-levelofthebuffer,theproducer(e.g.,CPUSM)wouldincreaseordecreaseitsservice,whiletheconsumer(e.g.,thenetworkSM)wouldtaketheoppositeaction.Thisapproachtoreal-rateschedulingrequiresservicemanagerstoshareinformationregardingbufferfill-levels.Tocompensateforthedifferentdelaysinaccessingthisinformation,thebufferisfillednomoreornolessthanspecificlevels.However,supposeaservicemanageraccessingthisinformationwastheothersideofalargelatencynetwork.Itmaybethatthelatencytomonitorthestateofthebufferistoolarge,andadaptationswillnotbeenactedfastenoughtomeetthenecessaryqualityofservice.Suchlargelatenciescancauseabuffertocompletelyfill,orcompletelyempty,therebyaffectingservicerate.Thisiswhatishappeningwiththeupstreamadaptationsinourexperiments.WepurposelydidnotsharestateinformationbetweentheCPUandnetworkservicemanagers,therebyobservingthecostofcommunicationbetweenthreadstocoordinateservice.
Inourexperiments,thedelayinsendinganeventtoahandlerwithinthesameservicemanagerthreadwas
,whileitwasashighas
betweenservicemanagerthreads.Inter-threadeventhandlingismore
expensivethanintra-threadeventhandling,duetothetime-sliceofathreadbeingfixedbytheoperatingsystemat
.Consequently,ifthenetworkservicemanagerobservesCPUserviceshouldbeadapted(whichisthecase
withupstreamadaptation),thereisadelayofmorethanbeforetheservicechangecanbeenacted.With
ratecontrol,theCPUisthecriticalresource,inthatframescannotbetransmittediftheyhavenotbeengeneratedand,inordertogenerateframes,aframe-generatorprocessneedsCPUcycles.Observethatwithdownstreamadaptation,wealsosendaneventfromamonitortoahandlerwithintheCPUservicemanager.Thedelayintransferringthiseventtoahandlerisonly
.Consequently,CPUcyclesareallocatedwithfiner-grained
controlindownstreamadaptationthanupstreamadaptation.Moreover,withdownstreamadaptation,eventscanbesentin-band,andinsynchrony,withtheflowofdatabetweenservicemanagers.Thisisnotpossiblewithupstreamadaptation,sinceserviceadaptationscannottypicallybeenactedbeforesubsequentdataistransferredalongthesamelogicalpath.Thismeansthetimebetweenwhenadaptationisnecessary,andthetimeitisappliedmayinvolveadaptationonanentirelydifferentdatasetwithupstreamadaptation.Consequently,upstreamadaptationstypicallyoccurout-of-bandwiththeflowofdata.
RateControl:Figure7showstheactualtransmissionratesofallthreestreamsusingthedifferentadaptationstrategies.Ascanbeseen,upstreamadaptationrequiresmoretimetoreachsteadystate,andtherearelarger
35
Actual Rate (Network Level)3025201510500
20
Downstream Adaptation
Target 10 fpsTarget 20 fpsTarget 30 fps
35
Actual Rate (Network Level)3025201510500
20
Upstream Adaptation
Target 10 fpsTarget 20 fpsTarget 30 fps
35
Actual Rate (Network Level)3025201510500
20
Intra-SM Adaptation
Target 10 fpsTarget 20 fpsTarget 30 fps
406080Time (seconds)
100120
406080Time (seconds)
100120
406080Time (seconds)
100120
Figure7.Networkserviceratewith(a)downstream,(b)upstream,and(c)intra-SMadaptation.
peak-to-peakoscillationsasthetargetrateistracked.Withupstreamadaptation,therearelargerdiscrepanciesbetweenCPUandnetwork-levelservicerates,whichisthereasonforlargerbuffervariations.Furthermore,sincetheactualandtargetserviceratesdiffermorefrequentlywithupstreamadaptationthanwithdownstreamandintra-SMadaptations,moreeventsarealsogenerated,asshowninFigure8(a),for
.Notethatwithdownstream
adaptation,network-leveleventsarenotactuallygenerated.However,Figure8(a)showshowmanynetwork-leveleventswouldbegenerated,duetodifferenttargetandactualservicerates,atthetimeserviceismonitoredbythenetworkservicemanager.
3000
Number of Events (Network-Level)250020001500100050000
5
10
DownstreamUpstreamIntra-SM
QoS Range ViolationsTarget 30 fps
60050040030020010000
5
10
Target 30 fps (+/- 10%)
600
Mean Queueing Delay (mS)50040030020010000
5
10
DownstreamUpstreamIntra-SM
Mean Queueing Delay (Target 30 fps)
DownstreamUpstreamIntra-SM
152025Time (seconds)
30
35
40
152025Time (seconds)
303540
152025Time (seconds)
303540
Figure8.(a)Cumulativenumberofnetworkeventsgeneratedbyeachadaptationmethod,(b)cu-mulativeQoSrangeviolations,and(c)meanqueueingdelayversustimeforbufferedframes,ofthe30fpsstream,
.
QoSRangeViolations:Notsurprisingly,Figure8(b)showsthattherearemostQoSrangeviolationswithup-streamadaptation.However,intra-SMadaptationisalsoworsethandownstreamadaptation.ThisisbecausethereisnocoordinationbetweenCPUandnetworkservicemanagers.Consequently,intra-SMadaptationrequiresmoretimethandownstreamadaptationtoreachthesteady-state,inwhichservicerateiswithinrangeofthemaximumandminimumallowedvalues.
MeanQueueingDelayandMissedDeadlines:Duetothehighestvarianceinthenumberofbufferedframeswithupstreamadaptation,thereisalsoamarkedlyhighervariationinmeanqueueingdelaytoo(asshowninFigure8(c),for
).Withupstreamadaptation,thesuddenincreasesindelayoccurwheneachstream'squeuelength(ring
bufferfill-level)increases.Furthermore,greatermismatchesbetweenserviceratesattheCPUandnetwork-levelsleadtomorevariationinbufferedframes,andmorevariationinmeanqueueingdelay.Asadirectconsequenceofbufferingvariationsand,hence,queueingdelays,therearepotentiallyhighernumbersofconsecutiveframeswithmisseddeadlines.Figures6(a)and(b)showthatdownstreamadaptationcausesfewerconsecutivemisseddeadlinesthanupstreamadaptation,whenthedeadlinesonconsecutiveframesofadaptationcausesalargestepinthenumberofmisseddeadlinesaroundinmisseddeadlineswithdownstreamadaptationareaslarge.
Insummary,differentadaptationstrategiesarepossiblewiththeDionisysQoSinfrastructure,using`qualityevents',monitorsandhandlers.Upstreamadaptationcanleadtopoorerqualitycontrol,ifadaptationlatenciesaresignificant.Thisisanalogoustotheproblemassociatedwithfeedbackcongestioncontrol[16],inthat,ifthetimetoinformtheproducerthatitshouldreduceitsgenerationrate,isgreaterthanthemaximumtimeavailabletoeffectivelyapplysuchanadaptation,thentheconsumercanbefloodedwithtoomuchinformation.Moreover,upstreamadaptationtypicallyoccursout-of-bandwiththeflowofdata.Withdownstreamadaptation,thedelaybetweengeneratingacontroleventandenactingthenecessaryservicechangecanbecoupledwiththetimetotransferapplicationdataalongthelogicalpathbetweenservicemanagers.Thatis,downstreamadaptationeventscanbesentin-band,andinsynchrony,withtheflowofdata.Bycontrast,intra-SMadaptationworkswellif:(1)coordinationbetweenresourcesand,hence,servicemanagersisnotanissue,or(2)thereisaccesstosharedstateinformation,whichallowsgroupsofservicemanagerstoimplicitlycoordinatetheirownserviceadaptations,whileavoidingthecostofcommunicatingqualityeventsbetweenoneanother.Finally,observethattheaboveadaptationstrategiesdifferinhow,when,andwhereserviceisadapted.Sincenosingleadaptationstrategyisalwaysbetterthananother,itisimportantforaqualityofserviceinfrastructuretobeflexibleinthewayitmanagesper-applicationqualityofservice.
are
apart.Upstream
seconds.Noneofthestepincreases
4.1.QoSManagement
WehaveshownhowtheDionisysQoSinfrastructureisflexibleenoughtosupportdifferentadaptationconfig-urations,allofwhicharenecessaryindifferentsituations.WenowshowhowtheflexibilityoftheDionisysQoSinfrastructureallowsqualityfunctionstobeembeddedintomonitorsandhandlers,toinfluencehowresourcesarebestallocatedamongstcompetingapplications.
Inthissetofexperiments,frame-generatorprocessesgenerated
framesforstream,
,
framesfor
and
framesfor
.Again,thetargetratesof
,
and
were
,and
framespersecond,respectively.ofthetargetrates.Furthermore,
Theminimumandmaximumservicerateswerenowallconstrainedtobe
Q180160140120100806040200300
1min/max rate (S) rounded off to the nearest integerOverall Quality25020015010050
(1)(3)(4)(2)23(1) Upstream (Q-biased)
(2) Upstream
(3) Downstream (Q-biased)
(4) Downstream
81012172023263034S (Rate, fps)
0
020
406080Time (seconds)
100120
Figure9.(a)QoSfunctionsforeachofthethreestreams,and(b)overallqualityversustime.
700600
QoS Range Violations50040030020010000
20
(1) Downstream (Q-biased), 10fps(2) Downstream, 10fps
(3) Downstream (Q-biased), 20fps
(4) Downstream, 20fps
(5) Downstream (Q-biased), 30fps
(6) Downstream, 30fps40
6080Time (seconds)
100
(1)(2)(4)(3)(6)(5)1000900800
QoS Range Violations700600500400300200100
120
00
20
(1) Upstream (Q-biased), 10fps
(2) Upstream, 10fps
(3) Upstream (Q-biased), 20fps
(4) Upstream, 20fps
(5) Upstream (Q-biased), 30fps
(6) Upstream, 30fps40
6080Time (seconds)
100
120(4)(3)(1)(6)(5)
(2)
Figure10.CumulativeQoSviolationsusing(a)downstream,and(b)upstreamadaptation.
tomodeltheeffectofdynamically-changingresourceavailability,
and
wereblockedforexponentially-distributedidletimes,aftergeneratingeachsetof
frames.Theexponentialidletimesaveragedseconds.
Thesamemonitoringandhandlingfunctions,asintheprevioussetofexperiments,wereusedhere.Asbefore,theCPUservicemanagerexecutedahandlerfunctionthatattemptedtoaltertheSolaris`RT'(real-time)priorityofthecorrespondingstream-generatorprocessbyanamountthatwasalinearfunctionofthedifferenceintargetandactualservicerates.TheextenttowhichaSolarisprioritywasalteredwasafunctionofthestream'sownqualityfunction.
TheactualqualityfunctionsthatwereusedareshowninFigure9(a).Thesefunctionsshowthequality(),
asperceivedbyeachstream,forthecorrespondingservicerate,
.Forexample,thepriorityof
isadjusted
byafactorof
morethanthepriorityof
(basedontheratioofthegradientsofthequalityfunctionsfortimesmorecriticalthanthe
and
).Inessence,thisimpliesthatis
,whentheactualandtargetservice
ratesofbothstreamsdifferbythesameamount.Likewise,
isthreetimesmore`qualitycritical'than.These
qualityfunctionscanbeincorporatedintomonitorsand/orhandlersofdifferentmanagers,assumingthereexistsafunctionaltranslation[10,8,15]fromtheserviceofferedbyagivenservicemanagertoapplication-perceivedquality.Exactlywhatagivenqualitymeanstoanapplicationisapplication-specific.
35
Actual Rate (Network Level)3025201510500
20
Downstream Adaptation
35
Actual Rate (Network Level)3025201510500
20
Upstream Adaptation
Target 10 fpsTarget 20 fpsTarget 30 fps
406080Time (seconds)
100
120
Target 10 fpsTarget 20 fpsTarget 30 fps
406080Time (seconds)
100
120
Figure11.Networkservicerate,with(a)downstreamadaptationandQ-biasing,and(b)upstreamadaptationandQ-biasing.
Figure9(b)showshowoverallqualityisimproved,usingdifferentadaptationstrategies,whenCPUserviceisbiasedtothemorequalitycriticalstream.The`Q-biasing'graphsrefertotheresultswhenthequalityfunc-tionsshowninFigure9(a)areused.Bycontrast,allothergraphsshowresultswhenCPUserviceisadjustedequallyforcompetingstreams,eventhoughonestream'sserviceisreallymorecriticalthananother's.Theoverallquality,
,wascalculatedfromthesumoftheaveragesampledqualityofeachstream.Thatis,
quently,servicemanagerscanusethisinformationtoimproveoverallqualityacrossallapplications.Thisissimilartoworkdonebyothers,usingvalue[17],reward[1]andpayoff[19]functions.
5.RelatedWork
Manyresearchgroupshaveproposeddifferentarchitecturesandmiddleware[4,13,27,20,2,26],toprovideruntimequalityofserviceguaranteesoninformationexchangedbetweenhostsinadistributedenvironment.How-ever,theDionisysQoSinfrastructurethatwepropose,focusesontheissuesofsupportingapplication-specificextensionsforqualityofservicemanagement,inaflexiblemanner.
AbdelzaherandShin[1]proposeanend-hostarchitectureforQoS-adaptivecommunicationthatcansupporthardandsoftreal-timeguarantees.AuserspecifiesaQoScontractthatconsistsofaseriesofalternativeQoSlevels,therewardsforachievingacertainQoS,andthepenaltyforviolatingrequiredQoS.Theaimistomaximizetheaggregaterewardacrossallusers,byselectingtheQoSlevelforeachuserthatachievesthebestoverallqualityasperceivedbyeveryone.Dionisyscomplementsthisworkbyrestrictingthesearch-spaceofservices(and,hence,resources)thatmustbeadaptedtomeetapplication-specificQoS.Eventchannelsrestrictserviceadaptationstoasubsetofallthepossibleadaptationsthatarepossibleinasystemattemptingtomaximizeoverallquality.Furthermore,DionisyscanutilizeAbdelzaherandShin'snotionofrewardfunctions,sothatservicemanagerscandecidehowbesttoallocateserviceamongstcompetingapplications.
TheDarwinprojectatCMU[6,7]isaimedatprovidingnetworksupportforapplication-orientedQoS.Centraltothisnetworkarchitectureisthenotionofaservicebroker,whichisresponsibleforlocatingavailableresourcesthatcanpotentiallybeusedtomeetapplicationrequirements,andidentifyingthoseresourcesamongallcandidatesthatmaximizesoverallqualitytoallapplications.InDionisys,brokersarereplacedbyservicemanagers,whichcoordinateresourceallocationandadaptationusingeventchannels.Ineffect,Dionisys'resourcemanagementisdistributedamongstservicemanagerslinkedbyapplication-specificeventchannels.
TheSWiFTtoolkit[11]hasbeenusedtoconstructfeedbackcontrolcomponentsinamodularfashion,tosupportadaptiveresourcemanagement[12].OnesuchapplicationoffeedbackcontrolusingSWiFTisareal-rateCPUscheduler[25].ThisisverysimilartothewayinwhichtheCPUservicemanagerinDionisyscanmonitorandadaptitsownserviceonbehalfofdifferentapplications.OurworkcomplimentsthisresearchbyshowinghowDionisyscansupportdifferentadaptationconfigurations(combinationsoffeedbackcontrolloops)tocoordinatemultipleservice(and,hence,resource)managers.Incoordinatingmultipleservicemanagers,resourcemanagementisessentiallydistributed,ratherthancentralized.Webelievethisapproachisbeneficialwhentheoverheadsofaglobalresourcemanagerwouldbetoocostly.Observethataglobalresourcemanagerhastogathermonitoringinformationaboutthestateofallresources,whichmayinvolvepassingsuchinformationacrossawideareanetwork,therebyincurringsignificantdelay.Afteracquiringsuchinformation,aglobalresourcemanagerthenhastodecidehowbesttoallocate
resourcesamongst
applicationsusinghintsprovidedtoitbyapplication-
specifichandlers.
TheabilityofDionisystosupportapplication-specificmonitorsandhandlersissimilartotheserviceextensionsdescribedinSPIN[3]andtheExokernel[9].AsinSPIN,Dionisyssupportsthedynamiclinkingofserviceexten-sions,whichhappentobelinkedintotheaddressspacesofservicemanagers.Similarly,theExokernelsupportsapplication-levelmanagementofhardwareresourcesbyexportingtheseresourcesthroughaninterfacetolibraryoperatingsystems.ExokernelandSPINdifferfromourworkbyfocusingonprotectionissues,insteadofQoSissuesforapplicationswithdynamicQoSrequirements.
OtherrelatedworkincludesEPIQ[15],whichistargetedatsupportingend-to-endQoSforcomplex,real-timeapplications,thatareinherentlypipelined(thatis,theapplicationshaveaseriesofdependenttasks,wheretheoutputofonetaskistheinputtoanother).ThisworkinvolvestheQoScharacterizationofpipelinedapplicationsandthecorrespondingmanagementofquality.Infact,thearchitectureusedintheEPIQprojectinvolvesbrokersforeachtaskinasequenceoftasksthatmakeuptheapplication.EachbrokermonitorsQoSfromitsproducertasksandnegotiateswiththebrokersoftheseproducertasks(aswellasconsumertasksandresourcemanagers)tomaintainQoS.HenceinteractionsamongQoSbrokersareconfinedtothosebetweenproducer/consumerpairs,whereasDionisysinvolvesinteractionsbetweenanyservicemanagerslinkedbyeventchannels.
Finally,ourworkcomplementsotherworkattheGeorgiaInstituteofTechnology,includingFARA[22,23],and`payofffunctions'[19]forcharacterizingthevalueofagivenqualitytoanapplication.PayofffunctionscanbeincorporatedintomonitorsinDionisys,toinfluencethetypeofeventthatisgeneratedwhenserviceadaptationsmustoccurtoachievequalityofaspecificvalue.InFARA,anadaptationandresourceallocationcoremakesthedecisionsaboutresourcereallocation,whereasDionisysusesapplication-specifichandlersintheservicemanagerstoinfluencesuchdecisions.
6.Conclusions
Thispaperdescribesanevent-basedmechanismintheDionisysQuality-of-Serviceinfrastructure,thatallowsapplicationstospecify:(1)howobservedqualityofserviceshouldbeadaptedtomaintainrequiredqualityofservice,(2)whenadaptationsshouldoccur,and(3)whereadaptationsshouldoccur.InDionisys,servicemanagersexecuteapplication-specificfunctionstomonitorandadaptservice(and,hence,resourceusageandallocation),inordertomeetthequalityofservicerequirementsofadaptableapplications.Thisapproachallowsservicemanagerstoprovideserviceinamannerspecifictotheneedsofindividualapplications.Moreover,applicationscanmonitorandpin-pointresourcebottlenecks,adapttheirrequirementsforheavily-demandedresources,oradapttodifferentrequirementsofalternativeresources,inordertoimproveormaintaintheirqualityofservice.Likewise,servicemanagerscancooperatewithotherservicemanagersand,byusingknowledgeofapplication-specificresourcere-quirementsandadaptationcapabilities,eachservicemanagercanmakebetterdecisionsaboutresourceallocation.Using`qualityevents',coordinatedresourcemanagementispossiblebetweenmultipleservicemanagers,eachre-
sponsibleforthemanagementofoneresourceabstraction.Havingservicemanagersexecuteapplication-specifichandlerstoadapttheirownservice,essentiallydistributescontrolofhowresourceadaptationshouldbedone.Again,suchcoordinationandcontrolwouldnotbepossiblewithoutamechanismlike`qualityevents'.
TheflexibilityoftheDionisysQoSinfrastructureenables:(1)differentadaptationstrategiestobeimplemented,using`qualityevents',monitorsandhandlers,and(2)qualityfunctionstobeembeddedintomonitorsandhandlers,toinfluencehowresourcesarebestallocatedamongstcompetingapplications.Servicemanagerscanusequalityfunctionstoimproveoverallqualityacrossallapplications.
Finally,severaladaptationstrategiesarecomparedinthispaper:namely,`upstreamadaptation',`downstreamadaptation'and`intra-SMadaptation'.Upstreamadaptationcanleadtopoorerqualitycontrolifadaptationlaten-ciesaresignificant.Thisisanalogoustotheproblemassociatedwithfeedbackcongestioncontrol[16],inthat,ifthetimetoinformtheproducerthatitshouldreduceitsgenerationrate,isgreaterthanthemaximumtimeavailabletoeffectivelyapplysuchanadaptation,thentheconsumercanbefloodedwithtoomuchinformation.Moreover,upstreamadaptationtypicallyoccurs`out-of-band'withtheflowofdata.Withdownstreamadaptation,thedelaybetweengeneratingacontroleventandenactingthenecessaryservicechangecanbecoupledwiththetimetotransferapplicationdataalongthelogicalpathbetweenservicemanagers.Thatis,downstreamadaptationeventscanbesent`in-band',andinsynchrony,withtheflowofdata.Bycontrast,intra-SMadaptationworkswellif:(1)coordinationbetweenresourcesand,hence,servicemanagersisnotanissue,or(2)thereisaccesstosharedstateinformation,whichallowsgroupsofservicemanagerstocoordinatetheirownserviceadaptations.
References
[1]T.AbdelzaherandK.Shin.End-hostarchitectureforQoS-adaptivecommunication.InIEEEReal-TimeTechnology
andApplicationsSymposium,Denver,Colorado,June1998.
[2]C.Aurrecoechea,A.Campbell,andL.Hauw.AsurveyofQoSarchitectures.MultimediaSystemsJournal,Special
IssueonQoSArchitecture,1997.
[3]B.N.Bershad,S.Savage,P.Pardyak,E.G.Sirer,M.Fiuczynski,andB.E.Chambers.Extensibility,safety,andper-formanceintheSPINoperatingsystem.InProceedingsofthe15thACMSymposiumonOperatingSystemsPrinciples,pages267–284,CopperMountain,Colorado,December1995.
[4]A.Campbell.Aqualityofservicearchitecture.InACMSIGCOMMComputerCommunicationReview.ACM,April1994.
[5]C.CarlssonandO.Hagsand.Dive-aplatformformulti-uservirtualenvironments.ComputersandGraphics,17(6):663–
669,November-December1993.
[6]P.Chandra,A.Fisher,C.Kosak,T.S.E.Ng,P.Steenkiste,E.Takahashi,andH.Zhang.Darwin:Resourcemanage-mentforvalue-addedcustomizablenetworkservice.InSixthIEEEInternationalConferenceonNetworkProtocols(ICNP'98),Austin,October1998.
[7]P.Chandra,A.Fisher,C.Kosak,andP.Steenkiste.Networksupportforapplication-orientedqualityofservice.InSixth
IEEE/IFIPInternationalWorkshoponQualityofService,Napa,May1998.
[8]G.Coulson,A.Campbell,andP.Robin.DesignofaQoScontrolledATMbasedcommunicationsysteminCho-rus.IEEEJournalofSelectedAreasinCommunications(JSAC),SpecialIssueonATMLANs:ImplemetationandExperienceswithEmergingTEchnology,May1995.
[9]D.R.Engler,M.F.Kaashoek,andJ.O.Jr.Exokernel:Anoperatingsystemarchitectureforapplication-levelresource
management.InProceedingsofthe15thSymposiumonOperatingSystemPrinciples,December1995.
[10]D.Ferrari.Clientrequirementsforreal-timecommunicationservices.IEEECommunicationsMagazine,28(11):76–90,November1990.
[11]A.Goel,D.Steere,C.Pu,andJ.Walpole.SWiFT:Afeedbackcontrolanddynamicreconfigurationtoolkit.Technical
Report98-009,OGICSE,1998.
[12]A.Goel,D.Steere,C.Pu,andJ.Walpole.Adaptiveresourcemanagementviamodularfeedbackcontrol.Technical
ReportCSE-99-03,OGICSE,January1999.
[13]G.GopalakrishnaandG.Parulkar.Efficientqualityofserviceinmultimediacomputeroperatingsystems.Technical
ReportWUCS-TM-94-04,DepartmentofComputerScience,WashingtonUniversity,August1994.
[14]S.GreenbergandD.Marwood.Real-timegroupwareasadistributedsystem:Concurrencycontrolanditseffectonthe
interface.InProceedingsoftheACMConferenceonCooperativeSupportforCooperativeWork,ACMpress,pages207–217.ACM,1994.
[15]D.Hull,A.Shankar,K.Nahrstedt,andJ.W.S.Liu.Anend-to-endQoSmodelandmanagementarchitecture.In
ProceedingsofIEEEWorkshoponMiddlewareforDistributedReal-timeSystemsandServices,pages82–89,December1997.
[16]V.Jacobson.Congestionavoidanceandcontrol.InACMComputerCommunicationReview:Proceedingsofthe
SIGCOMM'88,pages314–329.ACM,August1988.
[17]E.D.Jensen,C.D.Locke,andH.Tokuda.Atime-drivenschedulingmodelforreal-timeoperatingsystems.InIEEE
Real-TimeSystemsSymposium.IEEE,December1985.
[18]R.Kravets,K.Calvert,P.Krishnan,andK.Schwan.Adaptivevariationofreliability.InHPN-97.IEEE,April1997.[19]R.Kravets,K.Calvert,andK.Schwan.Payoff-basedcommunicationadaptationbasedonnetworkserviceavailability.
InIEEEMultimediaSystems'98.IEEE,1998.
[20]K.NahrstedtandJ.Smith.TheQoSbroker.IEEEMultimedia,2(1):53–67,1995.
[21]H.M.V.PawanGoyalandH.Cheng.Start-timefairqueueing:Aschedulingalgorithmforintegratedservicespacket
scwitchingnetworks.InIEEESIGCOMM'96.IEEE,1996.
[22]D.Rosu,K.Schwan,andS.Yalamanchili.FARA-aframeworkforadaptiveresourceallocationincomplexreal-time
systems.InProceedingsofthe4thIEEEReal-TimeTechnologyandApplicationsSymposium(RTAS),Denver,USA,June1998.
[23]D.Rosu,K.Schwan,S.Yalamanchili,andR.Jha.Onadaptiveresourceallocationforcomplexreal-timeapplications.
InProceedingsofthe18thIEEEReal-TimeSystemsSymposium(RTSS),SanFrancisco,USA,December1997.[24]S.Singhal.EffectiveRemoteModelinginLarge-ScaleDistributedSimulationandVisualizationEnvironments.PhD
thesis,StanfordUniversity,August1996.
[25]D.C.Steere,A.Goel,J.Gruenberg,D.McNamee,C.Pu,andJ.Walpole.Afeedback-drivenproportionallocator
forreal-ratescheduling.InInProceedingsofthethirdSymposiumonOperatingSystemDesignandImplementation.USENIX,1999.
[26]R.Vanegas,J.Zinky,J.Loyall,D.Karr,R.Schantz,andD.Bakken.QuO'sruntimesupportforqualityofservicein
distributedobjects.InProceedingsoftheIFIPInternationalConferenceonDistributedSystemsPlatformsandOpenDistributedProcessing(Middleware'98),LakeDistrcit,England,September1998.
[27]C.Volg,L.Wolf,R.Herrwich,andH.Wittig.HeiRAT-qualityofservicemanagementfordistributedmultimedia
systems.MultimediaSystemsJournal,1996.
[28]R.WestandK.Schwan.Dynamicwindow-constrainedschedulingformultimediaapplications.In6thInternational
ConferenceonMultimediaComputingandSystems,ICMCS'99.IEEE,June1999.AlsoavailableasaTechnicalReport:GIT-CC-98-18,GeorgiaInstituteofTechnology.
[29]R.West,K.Schwan,I.Tacic,andM.Ahamad.Exploitingtemporalandspatialconstraintsondistributedsharedobjects.
InProc.17thIEEEICDCS.IEEE,1997.
因篇幅问题不能全部显示，请点此查看更多更全内容