forIPNetworks
MartinMayandChristopheDiot
INRIABP93
06902Sophia-AntipolisCedex
France
{mmay,cdiot}@sophia.inria.fr
Abstract
TheIntegratedServicesPacketNetworksaredesignedtooffernewnetworkservicestoawidevarietyofapplications.Thearchitecturebehindthenewservicesconsistsprimarilyofapacketscheduler,apacketclassifier,admissioncontrol,andareservationestablishmentprotocol.ThispaperdescribesacompleteimplementationofthisTrafficControlexten-sions.WealsodesignedandimplementedakernelinterfacewhichpermitstosendQualityofService(QoS)requeststothenetworklayer.Weexplainhowtheelementsofthearchi-tectureworkinconcertandwhichmechanismsweusetoguaranteearequestedamountofbandwidth.OurschedulerusesavariantoftheClassBasedQueuingmechanism(CBQ)ofSallyFloydandVanJacobsen[6].ForthereservationsignalingandestablishmentweuseRSVP[2].Finallythispaperprovidesaperformanceevaluationoftheproposedmecha-nisms.
1Introduction
Today,theInternetisundergoingaperiodofrevolutionarychangetowardsreal-timeandmultimedia.Thisdeploymentisbaseduponfourenablingtechnologies.
Mostnewworkstationsnowincludebuilt-inmultimediahardware,includingaudiocodecsandvideoframegrabbers,andthenecessaryvideogearisnowadaysinexpen-sive.
Forthenewhardwareresources,highly-sophisticateddigitalaudioandvideoappli-cationshavebeendeveloped.Theseservices,availableintheInternet,arefreeofcharge(vic,rendez-vous,vat,ivs,Freephone...).
IPmulticasting,whichisnotyetgenerallyavailableincommercialrouters,isbeingprovidedbytheMBONE-atemporary\"multicastbackbone\".
Applicationsusingmulticasthavebeendeveloped.Theseapplicationsarenotonlyvideooraudio-conferencingtools;thefirstmulticastgamesarenowavailable.TheneedforapplicationslikedistributedgamesorDistributedInteractiveSimulation(DIS)isincreasing.
Thesetechnologiesallowwidely-scaleduseofaudioandvideoapplicationsovertheIn-ternet.Theresultsobtainedbytheseexperimentsshowthattime-constrainedapplicationsoftendonotworkwellintheInternetbecauseofvariabledelaysandnetworkcongestion.
Time-constrainedapplicationsarequitedifferentfromstandarddataapplications,andrequireservicethatcannotbedeliveredwithinthetypicaldataservicearchitecture.Onesalientcharacteristicofreal-timeapplicationsisthattheyrequireaboundonthedeliverydelayofeachpacket.Whilethisboundmaybestatistical,inthesensethatsomesmallfrac-tionofthepacketsmayfailtoarrivebythisbound,thebounditselfmustbeknownapriori.TheInternetusesdatagramswitchingasameansofdynamicallyallocatingnetworkre-sourcesonademandbasis.Connectionlessdatagramswitchingfacilitatestheinterconnec-tionofnetworkswithdifferentarchitecturesanditprovidesflexibleresourceallocationandgoodreliabilityagainstnodeandlinkfailure.However,itprovideslittlecontroloverthepacketdelayandlossprocessesattheswitches.
Tohandlethelackofcontroloverdelayandlossprocesses,anarchitecturewithanen-hancedschedulingmechanismisstillmissing.WorkisunderwayinvariousIETF(InternetEngineeringTaskForce)workinggroupstoincludenewservices[1]forapplicationsthatrequireaspecificqualityofservice.Theyalsodefinenewprotocols(likeIPv6[8]orRSVP[2])tosimplifytheintegrationofresourcecontrolinthecurrentInternet.
Butreal-timeQoSisnottheonlyreasonforanextgenerationoftrafficmanagementintheInternet.Networkoperatorsrequesttheabilitytocontrolthesharingofbandwidthonaparticularlinkamongdifferenttrafficclasses.Theywanttobeabletodividetrafficintoafewadministrativeclassesandassigntoeachaminimumpercentageofthelinkbandwidthunderconditionsofoverload,whileallowing\"unused\"bandwidthtobeavailableatothertimes.Theseclassesmayrepresentdifferentusergroupsordifferentprotocolfamilies,forexample.Suchamanagementfacilityiscommonlycalledcontrolledlink-sharing[6].ThedesignandimplementationoftheINRIATrafficControlkernelsupportsthefea-turestoallocateresources,toguaranteedelaybounds,andtosharethebandwidthamongdifferenttrafficclasses.Thereservationestablishmentandsignaling(intheuserspace)isdonebytheReSerVationSetupProtocol(RSVP).
Inthispaper,wedescribetheTrafficControlkernelsupportforresourceallocation,scheduling,andlink-sharing.Section2givesanoverviewofourarchitecture.Insection3,weintroducethemaincomponentsofourtrafficcontrolsystem.Then,insection4,wepresenttheresultsoftheperformancemeasurements.Section5concludesthepaper.
2OverviewoftheTrafficControlArchitecture
Datagram-basednetworks(inourcaseIP-networks)arescalableandflexible,buttheyre-quiremorecomplexmechanismsand,infact,evenfundamentalchangestotheirarchitec-turetoprovidealargersetofservices.TodaytheInternetusesaservicemodelcalled“besteffort”.Inthismodel,thenetworksharesbandwidthamongalltheinstantaneoususersasbestitcan,andattemptstoserveallofthemwithoutmakinganyexplicitcommitmentastorateoranyotherservicequality.
Theservicesofferedbythenetworkdependontherouterarchitectureandtheimple-mentedmechanismsinthenetworknodes.InthepacketforwardingpathofIPimplemen-tations,thereisaverylimitedsetofactionsaroutercantake.Givenaparticularpacket,theroutermustselectarouteforit;inadditiontheroutercaneitherforwarditordropit,andtheroutercanreordertheoutgoingqueuewithrespecttootherpacketswaitingtodepart.Theroutercanalsoholdthepacket,eventhoughthelinkisidle.
TosupportthenewservicesweaddedsomenewelementstotheclassicarchitectureoftodaysIPimplementationsasillustratedinFigure1.Thefirstnewelementisapacketclassifier.Thetaskoftheclassifieristoexamineallincomingpacketsanddeterminethecorrespondingtrafficflowforit.Ifthereisnocorrespondingtrafficflowfound,thepacketismarkedforbest-efforthandling.
Besidetheclassifier,weneedamoresophisticatedschedulerthanasimpleFIFOmech-anism.Thisschedulermusthandlethedifferentflowsaccordingtothereservationmadeforthatflow.Examplesofsuchschedulerscouldbefoundin[15][9][10].FortheINRIA
ApplicationRSVP DaemonUser-SpaceKernel-SpaceSetup-toolInterfaceAdmission ControlSchedulerIP-ForwardFromlast RouterIP-OutputTo nextRouterClassifierFigure1:ArchitectureoftheINRIATrafficControlKernel
TrafficControlkernel,weimplementedavariantoftheClassedBasedQueueingalgorithm[7].
Forthereservationestablishmentandsignaling,weusedtheISIversionofRSVP.TheRSVPprotocolimplementsthemechanismstomakereservationsalongthesendingpathofadataflow.OurRSVPDaemoncommunicateswithourtrafficcontrol(TC)elementsinthekernelviaanewinterfacewehavedesignedandaddedtoRSVP.
Finally,wehaveimplementedasimpleAdmissionControl.TheAdmissionControlmoduleislyinginbetweenRSVPandthekernelwiththeclassifierandthescheduler.Ad-missionControlimplementsadecisionalgorithmthattherouterusestodeterminewhetherarequestedserviceforanincomingflowcanbeguaranteedwithoutimpactingearlierguar-anteesornot.Itcanbeimplementedinkerneloruserspace.ButsinceitislogicallypartoftrafficcontrolweplacedAdmissionControlinthekernel.
WedevelopedasimpleTcl/TktooltopasscontrolinformationdirectlytotheTCele-mentsinthekernel.TheSetup-Tool(seeinFigure1)isusedtosetupandmaintaintheelementsofthearchitecture.
ThisarchitectureallowsustooffertheservicesdefinedbyIntServ[1].Thetwoimpor-tantclassesaretheguaranteedqualityofservice[11]andthecontrolledloadservice[14].Guaranteedserviceensuresthatdatagramswillarrivewithintheguaranteeddeliverytimeandwillnotbediscardedduetoqueueoverflows,providedtheflow’strafficstayswithinitsspecifiedtrafficparameters.Thisserviceisintendedforapplicationswhichneedafirmguaranteethatadatagramwillarrivenolaterthanacertaintimeafteritwastransmittedbyitssource.
Thecontrolledloadserviceisintendedtosupportabroadclassofapplicationswhichhavebeendevelopedforuseintoday’sInternet,butarehighlysensitivetooverloadedcon-ditions.Importantmembersofthisclassarethe\"adaptivereal-timeapplications\"currentlyofferedbyanumberofvendorsandresearchers.Theseapplicationshavebeenshowntoworkwellonunloadednets,buttodegradequicklyunderoverloadedconditions.
3TrafficControlArchitecture:Classifier,Scheduler,andAdmissionContol
ThissectiondescribesthedesignandimplementationofsignificantcomponentsoftheTCkernel:thescheduler(basedontheClassedBasedQueueingalgorithm[7]introducedbySallyFloydandVanJacobson)andtheclassifier.Then,weexplainthemechanismsinthekerneltocalculatetheparametersforthescheduler,andhowthereservationrequestispassed
fromtheRSVPdaemon1tothekernel.
3.1TheClassifier
Asmentionedabove,atodaysrouterlooksatthedestinationaddressoftheincomingpacketandselectsarouteforit.Butthedestinationaddressisnotsufficienttoselecttheserviceclassforeachincomingpacket.Ourapproachistolookatmorefieldsinthepacketheader,suchassourceaddressandthedestinationandsourceports.Thisallowsustodistinguishbetweenthedifferentdataflows,likeUDPvideooraudiostreams,ordifferentTCPtelnetorFTPflows.
Foreachdataflowweaddafiltertotheclassifier.Thefilterincludesthesourceanddestinationaddress,thesourceanddestinationports,andapointerorflowhandletothecorrespondingserviceclass.
Whenapacketarrivesattherouterwedoanhashtablelookuptofindthecorrespondingfilterentrywiththepointertoappropriateoutgoingqueue.Ifnofilterentrywasfound,thepacketisclassifiedforthebest-effortserviceandmettothedefaultoutgoingqueue.
Theclassifierimplementationissuesarecomplexityandprocessingoverhead.Tore-ducetheprocessingtimeforeachpacketthesefilterinformationisstoredinahash-tablewhichpermitsafastaccesstimesevenforlargetablesizes.
3.2ThePacketScheduling
Futureintegratedservicesnetworks[3][5]willsupportmultipleserviceclassesthatincludereal-timeservice,best-effortservice,andothers.Inaddition,theywillneedtosupportcon-trolledlink-sharing[6].
WeimplementedavariantofClassBasedQueueing(CBQ)basedontheimplementationofSallyFloyd[7].Thisschedulerintegratesthepostulatedfeatures.Theconceptualframe-workforCBQassumestwoschedulingmechanisms:ageneralschedulerthatschedulesthepacketsfromleafclasseswithoutregardtolink-sharingguidelines,andalink-sharingschedulerthatsurveysthattheleafclassesdonotexceedtheirlink-sharingallocations.Bothschedulersareintegratedinoneschedulingalgorithm.
InourTCKernelweuseaseparatequeueforeachclassassociatedwiththeoutputlink.Afterapacketistransmittedontheoutputlink,theschedulerdecideswhichclassisallowedtosendthenextpacket.Thisnextclassisselectedinpriorityorder.Withinclassesofthesamepriority,theschedulerusesavariantofweightedround-robin(proportionaltotheallo-catedbandwidth).Theweightsdeterminethenumberofbytesthisclassisallowedtosendateachround.InFigure2weillustratethearchitectureoftheCBQscheduler.Theweightedround-robinensuresthateachpriority-oneclassreceivesitsallocatedbandwidth.
Beforethegeneralschedulertransmitsapacket,theschedulerchecksifthereistimelefttosend,bycomparingthetime-to-sendfieldwiththecurrenttime.Ifthetime-to-sendfieldisgreaterthenthecurrenttime,theschedulercanonlysendthepacketifthelink-sharingpermitstoborrowbandwidthfromhigher-levelclasses.Theleafclassescantrytoborrowbandwidthfromallparentclassestheyarelinkedwith.FormoredetailsaboutClassBasedQueueingandlink-sharingwereferto[6].
InFigure2weshowanexampleforalink-sharinghierarchy.Considerforthisexamplenorganizationssharingonoutputlink.Theadministrativepolicysurveysthatorganization1(orShare1)getsatleast25%ofthelinkbandwidth.InsightShare115%ofitsbandwidthisreservedforreal-timetraffic.Beside5%forbest-efforttraffic,theorganizationcanreserveupto5%ofitsbandwidthtootherapplications,likeFTPortelnet.
InourimplementationofCBQwehaveatreerepresentationofthehierarchy.Thephys-icallinkrepresentstherootnodeofthetreeandtheleafnodesrepresentaphysicalqueue.Eachleafnodeisconnectedtooneparent.Wealsoincludedapointertothenodetheleaf
Link
Link
Prio 7Prio 0
25%
10%
10%
5%
S 1
S 2S 3S n
defaultqueue15%5%
1%4%
real-time queues
low priorityqueues
Real-TimeBest-EffortReal-Time
Telnet
(a) Scheduler Architecture
(b) Link Sharing Tree
Figure2:LinkSharingExample
canborrowbandwidthfrom.Thatforthelink-sharinghierarchymaydifferfromthelogicalhierarchy.
Foreachnewclassweaddtotheschedulerwehavetospecifyitscharacteristics.Thesearedefinedbythefollowingvalues:
forthecorrespondingflow.
oftheclass[0..7].
max.queuelength.Withthisinformationamaximaldelaycanbeguaranteedbythescheduler.
.Theparameterofftimegivesthetimeintervalthataoverlimitclassmust
waitbeforesendinganotherpacket.Thisparameterdeterminesthesteady-burstsizeforaclasswhentheclassisrunningoveritslimit.
.Thevariableidleisthedifferencebetweenthedesiredtimeandthemea-suredactualtimebetweenthemostrecentpackettransmission.Theparameterlimitstheupperboundfortheaverageidletime.Thusboundsthecreditgiventoaclassthathasrecentlybeenunderitsallocation.
3.3AdmissionControl
Inordertoinsurethatcommitmentsmadeforcertainclassesofpacketscanbemet,itisnecessarythatresourcesbeexplicitlyrequested,sothattherequestcanberefusediftheresourcesarenotavailable.Thedecisionaboutresourceavailabilityiscalledadmissioncontrol.
Admissioncontrolusesthetokenbucketvaluesfortherequestedbandwidthtodecide,whetherthebandwidthforthedesiredbandwidthcanbeguaranteedornot.Oursimplead-missioncontrolcalculatetheallocationforaguaranteedservicewith,
thetokenbucketrate,andthetokenbucketwhereistherequestedbandwidth,
depth.Foracontrolledloadservicetheallocationcorrespondsto.Admissioncontrolacceptstheflow,if
wheredenotesthereservedbandwidthforthetypeofservice.Thisamountofbandwidthissetduringthesetupphaseoftherouter.
Whenwewanttoguaranteeamaximumdelaybound,admissioncontrolneedsamorecomplexscheme.Theadmissioncontrolalgorithmforsuchtypeofservicedemandswhetherahardlimitationofthenumberofguaranteedflowsoragreatshareofthebandwidth,us-ingthetheoreticalapproachofParekhandGallager.Tofindouthowmuchbandwidthwehavetoreserveforacertaindelayboundweconsulttheirwell-knownequationforthedelaybound
wheretion.
istherequestedbandwidth.Thevalueof
issetbytheuserorapplica-
3.4TheTrafficControlInterface
AcentralnoveltyinIPnetworks,isthenewTCinterfacewecreatedforourarchitecture.ThisinterfacepermitstopassQoSrequestsfromuserspacetothekernel.
ForfuturecompatibilitywehavechosenagenericspecificationfortheQoSrequestswepassthroughourTCinterface.ThesetofgeneralcontrolandcharacterizationparametersusedbynetworkelementssupportingtheintegratedservicesframeworkisdefinedintheIn-tegratedServicesWorkingGroup[1].Weusetheirtrafficspecification(TSPEC)parametersdefinedinReference[12],todescribethetrafficcharacteristicsofthedataflow.
Weuseasingletc_requeststructureforallservicerequests.Thisstructureincludesthetypeoftherequest(e.g.ADD_SHARE,ADD_FILTER,ENABLE_TC,orMOD_FLOW)andthecorrespondingparameters.TherequestsareusedbyourSetup-ToolandRSVP.TherequeststomanipulatetheflowsandfiltersareonlyusedbytheRSVPdaemon.TheserequestsusetokenbucketTSPECvaluestodescribetherequiredflowcharacteristics.
andabucketdepth.Atokenbucketspecificationincludesanaverageortokenrate
Bothandmustbepositive.ThetokenbucketTSPECtakestheformofatokenbucketspecificationplusapeakrate,minimumpolicedunit,andamaximumpacketsize.Foraguaranteedservicethevaluesforamaximumdelayandservicerateareadded.
Thetc_requestalsoincludesfilterinformation.ThesearethesourceanddestinationaddressandforIPv4thesourceanddestinationportnumbersoftheUDPorTCPheaders.
ForIPv6,wedonotneedtheportnumberstoclassifytheincomingpackets,insteadweusetheflow-IDfield.
Besidetheserequests,wecanusetheinterfacetoaskthecurrentstateoftherouter.Wecollectstatisticslikethenumberofdroppedpackets,orthemeanqueuesizeofallflows.
3.5ReservationMechanisms
DuringtheinitializationoftherouterwebuilduptheclasshierarchyforCBQ.ThereforeweaddasharedRSVPclasstotherootofthelink-sharingtree.Inourtestswetook80percentoftheavailablebandwidthforRSVPtraffic.Allclassesaddedtothissharearefrompriority7.Thenweaddanothersharedclassforeachserviceweoffer.Uptonow,thisisacontrolledloadserviceshareandaguaranteedserviceshare.ThisservicehierarchyisshowninFigure3.
Thequeuesforallnewflowsarethenlinkedtothecorrespondingsharetreenodesoftheserviceclasses.
ThedrivingengineofourTCkernelisRSVP.DetailsaboutRSVPandtheuseofRSVPcanbefoundin[2]or[13].AnapplicationusestheAPI(ApplicationProgrammingIn-terface)ofRSVPtopassthedesiredtrafficparameterstowardsthenetwork.ThenRSVPconvertstheAPIvaluestothegeneraltrafficspecificationvalues.Thesevaluesarecopiedinournewtc_requeststructureandthenpassedthroughtheTCinterfacetothekernel.Whenareservationmessagearrivesattherouter,RSVPtriestomakeareservationforthenewflow.TheRSVPdaemonpassesamessagetothekernel(toadmissioncontrol)viathenewTrafficControlinterface.Thisrequestincludesaservicedefinition,therequestedbandwidthinatokenbucketnotation,additionalinformationlikeamaximumdelay,themaximumpacketsize,andvaluesforamaximumpacketburst.
Whentheparametersforthenewclassarecalculated,theclassislinkedtothelink-sharingtree.ThentheRSVPdaemonpassesthefilterinformationtotheclassifier.Thenwecalculatesthehashtablekeysandinsertthefilterinthehashtable.
WhenareservationisfinishedandaTEARDOWNmessagearrivesattherouter,theclassforthesessionisremovedfromthelink-sharingtree.Foradmissioncontrolweaddthereservedbandwidthtotheavailablebandwidth.Finallyweremovethefilterinformationfromthehashtable.
4PerformanceEvaluation
Inthissection,wepresenttheresultsofourperformanceevaluationtoillustratethedelayandthroughputpropertiesoftheINRIAtrafficcontrolkernel.Todemonstratethetightnessofourapproachtowardstrafficcontrol,wecontrastthedelaydistributionandthroughputofourintegratedservicesrouterwithabest-effortrouter.Theexperimentswereconductedonourlocaltest-bedatINRIASophiaAntipolis.WeusedapoolofeightPCs(PentiumPProwithMByteRAM)runningamodifiedversionofLinuxversion2.1.23.
InFigure3,weseethenetworksetupweusedtomeasurethepacketdelayandband-widthcharacteristicswithourINRIATCkernel.ThePCareconnectedto10MBit/sether-netswhichwereexclusivelyusedbythePC.SomePCarelinkedtomorethenonenetwork(liketheroutersorthePCweusedforthedelaymeasurements).TheroutersarealsoPCwiththesameconfigurationastheothermachines.
WecreatedasharedclassforallRSVPflows.Thisclasshasaguaranteedshareof0.8fromitsparentnodewhichisthelinkitself(10Mbit/s).Then,webuiltupaclassforallcontrolledloadserviceflows(CLS).Thisclassreservedashareof0.6fromtheRSVPparentclass.ThelinksharingsetupisshowninFigure3.
Tosetupthereservationsintheintermediaterouters,weusedtheRSVP-toolsincludedintheISIdistributionofRSVP.TheparametersforthereservationcorrespondtothetokenbucketnotationoftheRSVPspecification.
PCPCPC
PC
PC
PC
80%
10 Mbps
20%
Default
40%
Guaranteed Service
INRIA-TC kernel
PC
INRIA-TC kernel
INRIA-TC kernel
background trafficreserved flowreserved flow
RSVP share
60%ControlledLoad160kbs
300kbsINRIA-TC kernel
PC
Flow 1Flow 2Flow 1PCPC
PCPC
(a) Setup for Delay Measurements(b) Network Setup for Bandwidth Measurements(c) Setup used for RSVP classes
Figure3:NetworkSetupforthePerformanceEvaluation
0.20.180.160.140.12Delay in ms0.10.080.060.040.020
’Delay_with_CBQ’’Delay_with_FIFO’050001000015000
2000025000Number of Packet
3000035000
(b) Delay experienced
Figure4:AbsolutedelayexperiencedbyFIFOandCBQscheduling
4.1DelayCharacteristics
Inthissection,wecomparethepacketdelaydistributionsforadataflowundertwoschedul-ingmechanisms,FIFOandCBQwithareservationfortheflow.ThereforeweuseRSVPtocreateacontrolledloadsessionforthedatapackets.Sincethecontrolledloadservicewillbeusedbyadaptivereal-timeapplicationsusingUDP,wemeasuredthedelayofaUDPses-sionsendingburstsabout4packetsinarow,eachpacketwithasizearound500bytes.Thesizeofthepacketsarevariedduringtheobservationtime.
WeaddedanewclassforthenewflowtotheCLSsharetreenode.Thisclassallocated200kbyte/s.WemeasuredthedelayofthepacketswithonePCassenderandreceiver.Allpacketsarescheduledinbothintermediaterouters(compareFigure3).TosimulateacongestednetworkweusedtheotherPCstogeneratethebackgroundtrafficbysendingTCPandUDPpackets.
InFigure4,weshowthedelaycharacteristicsoftheUDPpacketsfromthemeasuredflow.Allpacketsofthisflowtraversingthetwotrafficcontrolrouters.WeseethatwhenweuseFIFOschedulingintherouters,theworstcasedelayincreasessubstantially.Whentheroutersusedourtrafficcontrolextensions,thedelayremainsstable.Wealsoobserve,thatthedelayvarianceoftheun-scheduledFIFOpacketsisgreaterthanthevarianceoftheCBQscheduledtraffic.
Flow n40000
Flow 2200180160140
Bandwidth in kbyte/s120100806040200
’100_kbs’’150_kbs’’200_kbs’’250_kbs’’300_kbs’’300_kbs’’300_kbs’02040
60Time in sec
(a) with FIFO scheduling
80100120
350
’100_kbs’’150_kbs’’resv. 200_kbs’
’250_kbs’’300_kbs’’300_kbs’’resv. 300_kbs’
300
250
Bandwidth in kbyte/s200
150
100
50
0
02040
6080Time in sec
(b) with CBQ and reservations
100120
Figure5:MeasuredBandwidthwithFIFOandCBQScheduling
4.2BandwidthScheduling
Inthissection,weanalyzehowourtrafficcontrolimplementationprovidesbandwidthreser-vation.ForthebandwidthmeasurementsweusedthenetworksetupillustratedinFigure3.Thesetupfortheschedulerclassesisidenticaltotheoneweusedforthedelaymeasure-ments.
Theadvantagesofbandwidthreservationismorevisiblewhenwereservebandwidthformorethanoneflow.Thereforewecreatedtwosessionsfortwodifferentflows.Theseflowsrequestedacontrolledloadservice.Forthefirstsessionwereserved300kbyte/sandforthesecond160kbyte/sfromtheavailablebandwidthoftheCLSshare.BothsessionsaresendingUDPpacketslikeinsection4.1.Whilesession1sends300kbyte/s,session2sendsmorethentheallocatedbandwidth(200kbyte/sinsteadoftheallocated160kbyte/s).Thetwonewsessionsarethenaddedtothescheduler.Sincetheflowdemandedacon-trolledloadservicetheywerelinkedtotheCLSshareclass.
Figure5showsthebandwidthvs.timegraphsforeachUDPsessionsunderconsider-ation.Thesessionssendwithratesof100kbyte/s,150kbyte/s,200kbyte/s,250kbyte/sandthreesessionswith300kbyte/s.Allsenderstogethersendabout
;thatmeansthattheethernetlinkisheavilyloadedduringtheob-servationtime.
Figure5showstheeffectivebandwidthusedbyeachflowwithanordinaryFIFOschedul-ing.InFigure5weshowtheresultsobtainedwithareservationof160kbyte/sforthe200kbyte/s(session2)anda300kbyte/sallocationforoneofthethree300kbyte/sflows(ses-sion1).
Theobservedresultsconfirmwhatwasexpected.WhentheroutersusingaFIFOschedul-ingstrategyallflowssuffersunderthecongestion.Themaximumrateaflowachievedwasabout183kbyte/s.Theresultswiththereservationsshowstheadvantagesofsophisticatedschedulingmechanisms.Allreservedsessionskepttheirallocatedbandwidthwhilethebandwidthofthenon-reservedflowsdegradetoaminimumrateguaranteedbythedefaultqueueofthescheduler.
5Conclusion
Inthispaper,wepresentedourapproachtowardsTrafficControlinIPnetworks.Wedis-cussedhowthiswasdoneandtheexperiencesgainedwhileimplementingitselements.Whilemanypaperspresentsimulationresultsandtheoreticalapproachestowardsinte-gratedservicesnetworks,weimplementedandtestedthebehaviorofthismechanismsinarealnetwork.Ourmeasurementsconfirmedthatitispossibletoguaranteeacertainband-widthforalimitednumberofsessions.Forthesesessions,wealsoachievedtokeepaav-eragedelayonalowlevel.
Thissituationwouldchangeforaguaranteeddelayservice.Whenweusetheequationdescribedinsection3.3,thebandwidthwouldnotbeefficientlyuse.Theclassesfortheguaranteedservicewouldallocatetoomuchoftheavailablebandwidth.
Inallourmeasurements,alsowithmorethan2routersandwithareservationof200kbytespersecforthatflow,thedelayneverraisedabove40ms.Weachievedtheseresultswithoursimpleadmissioncontrol.Thisconfirms,thatforthemostapplicationsmuchsim-plermechanismsaresufficienttomeettheapplicationneeds.
Asmentionedbefore,RSVPisnotthecentralelementinourarchitecture.Incontrast,weconsiderRSVPasaheavy,inflexibledrivingengineforreservationestablishment,par-ticularlyfortheweakserviceguaranteeswecanget(e.g.withguaranteeddelayservice).InthefutureweintendtodevelopalightversionofanIntegratedServicesInternet.WewanttosimplifytheapproachoftheIntServworkinggroupintermsofareducedsetofof-feredservices.ThisarchitecturewillalsoincludesomethinglikealightversionofRSVP.Thisarchitecturewillincludeextensionsthatcanprovidediscriminationintheserviceof-feredtodifferentusersintimesofnetworkcongestion[4].
ThemaincontributionofthisworkwillbetorealizetheIntegratedServicesarchitecturewithmuchsimplermechanismsthenthoseproposedbytheIntServworkinggroupandalsotointegrateapricingschemefromthestartinthearchitecture.
References
[1]Braden,R.,Clark,D.,andS.Shenker,“IntegratedServicesintheInternetArchitecture:an
Overview”,RFC1633,ISI,MIT,andPARC,June1994.[2]Braden,R.,etal.,“RSVP:ANewResourceReSerVationProtocol”,IEEENetwork,September
1993.[3]Clark,D.,Shenker,S.,Zhang,L.“Supportingreal-timeapplicationsinanintegratedservices
packetnetwork:ArchitectureandMechanisms”,ProceedingsofACMSIGCOMM’92,pages14-26,Baltimore,Maryland,August1992.[4]Clark,D.,\"AddingServiceDiscriminationto
www.lcs.mit.edu/anaweb/papers.html,September1995.
the
Internet\
URL
http://ana-
[5]Ferrari,D.,VermaD.,“Aschemeforreal-timechannelestablishmentinwideareanetworks”,
IEEEJournalonSelectedAreasinCommunication,Vol.8,368-379,April1990.
[6]Floyd,S.,\"Link-sharingandResourceManagementModelsforPacketNetworks\Submitted
toACM/IEEETransactionsonNetworking.[7]Floyd,S.,WWWpageforCBQ,URLhttp://www-nrg.ee.lbl.gov/floyd/cbq.html
[8]Huitema,C.,”IPv6TheNewInternetProtocol”,PrenticeHall,UpperSaddleRiver,NewJersey,
1996.[9]Keshav,S.,OntheEfficientImplementationofFairQueueing”,JournalofInternetwork-ing:ResearchandExperience,V2,N3,September1991.[10]Parekh,A.andGallager,R.,”AGeneralizedProcessorSharingApproachtoFlowControl-The
SingleNodeCase”,TechnicalReportLIDS-TR-2040,LaboratoryforInformationandDecisionSystems,MIT,1991.[11]Shenker,S.,Partridge,C.,Guerin,R.,“SpecificationofGuaranteedQualityofService”,draft-ietf-intserv-guaranteed-svc-06.txt,August1996.[12]Wroclawski,J.,Shenker,S.,\"GeneralCharacterizationParametersforIntegratedServiceNet-workElements\draft-ietf-intserv-charac-02.txt,October1996.[13]Wroclawski,J.,“TheUseofRSVPwithIETFIntegratedServices”,draft-ietf-intserv-rsvp-use-01.txt,October1996[14]Wroclawski,J.,“SpecificationoftheControlled-LoadNetworkElementService”,draft-ietf-intserv-ctrl-load-svc-04.txt,November1996.[15]Zhang,L.,“VirtualClock:ANewTrafficControlAlgorithmforPacketSwitchingNetworks”,
ACMTransactionsonComputerSystems,9(2):101-124
因篇幅问题不能全部显示,请点此查看更多更全内容
Copyright © 2019- howto234.com 版权所有 湘ICP备2022005869号-3
违法及侵权请联系:TEL:199 1889 7713 E-MAIL:2724546146@qq.com
本站由北京市万商天勤律师事务所王兴未律师提供法律服务