An Experimental Implementation of Traffic Control for IP Networks

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