Integrated and Differentiated ServicesChristos PapadopoulosCS551 Fall 2002(http://netweb.usc.edu/cs551/)

MotivationSome applications require minimum level of network performanceSome less elastic applications are not able to adapt to changes in bandwidth and delaybandwidth below which video and audio are not intelligibleinternet telephones, teleconferencing with high delay (200 - 300ms) impair human interaction

The Problem

A Class of Real-time ApplicationsPlayback applicationsset a playback point in the futurebuffer packets until playback pointFeatures that you can leverageearly packet arrival okperformance improves with lower delayneed absolute or statistical bound on delaytolerate some loss

Rigid V.S. Adaptive ApplicationsTwo classes of playback applicationsRigid/adaptiveTolerant/intolerantThe distinction here is whether the application would tolerate interruptionsRigid applicationsSet fixed playback point (a priori bound)Adaptive applicationsAdapt playback point (de facto bound)A priori bound > de facto bound

Adaptive ApplicationsGamble that network conditions will be the same now as in the pastAre prepared to deal with errors in their estimateWill in general have an earlier playback point than rigid applicationsExperience has shown that they can be built (e.g., vat, various adaptive video apps)

Real-time Applications

Architectural ComponentsCommitments made by networktype of service the network providesService interfacecharacterization of source trafficcharacterization of QoS network will deliverPacket schedulingalgorithms, information in headersAdmission controlpolicing

Types of Network Service CommitmentsGuaranteed serviceFor intolerant and rigid applicationsPredicted serviceFor tolerant and adaptive applicationsApplications gamble, why not the network?Two components:If conditions do not change, commit to current serviceIf conditions change, take steps to deliver consistent performance (help apps set playback point by minimizing post facto delay bounds)

Service Interface: FlowspecsTspec: describes the flows traffic characteristicsRspec: describes the service requested from the network

Token Bucket FilterDescribed by 2 parameters:token rate r: rate of tokens placed in the bucketbucket depth B: capacity of the bucketOperation:tokens are placed in bucket at rate rif bucket fills, tokens are discardedsending a packet of size P uses P tokensif bucket has P tokens, packet sent at max rate, else must wait for tokens to accumulate

Token Bucket OperationtokensPacketoverflowtokenstokensPacketEnough tokenspacket goes through,tokens removedNot enoughtokens - wait fortokens toaccumulate

Token Bucket CharacteristicsIn the long run, rate is limited to rIn the short run, a burst of size B can be sentAmount of traffic entering at interval T is bounded by:traffic = B + r*TInformation useful to admission algorithm

Token Bucket SpecsBWTime12123Flow AFlow BFlow A: r = 1 MBps, B=1 byteFlow B: r = 1 MBps, B=1MB

Possible Token Bucket UsesShaping, policing, marking delay pkts from entering net (shaping) drop pkts that arrive without tokens (policing) let all pkts pass through, mark ones without tokensnetwork drops pkts without tokens in time of congestion

Guarantee Proven by ParekhSuppose a flow gets a rate r at every router in networkand all routers in network do WFQ and the corresponding token bucket burst size is bThen, in any arbitrary topologyCumulative queuing delay Di suffered by flow i has upper bound b/reven if the switch is shared with unshaped flowsThis result holds for a fluid flow approximationAdditional terms to the delay bound with a packet approximationIntuition:Imagine flow i shaped with token bucket, then all delay is incurred at entrance to network

Scheduling Guaranteed TrafficUse token bucket filter to characterize trafficUse WFQ at the routersParekhs bound for worst case delaySo why not only have guaranteed and best effortDelays can be high unless one reserves a rate r which is higher than the average rateNetwork can then be significantly underutilized

Predicted ServiceWFQ not suitableProvides isolation, but the delay is not shared and can self-impose jitter in post facto delayFIFO with multiple priority levels might workBut jitter can increase in a multi-hop caseSo, use FIFO+At each hop: measure average delay for class at that routerFor each packet: compute difference of average delay and delay of that packet in queueAdd/subtract difference in packet header

Predicted Service: FIFO+ SimulationSimulation shows:slight increase in delay and jitter for short pathsslight decrease in mean delaysignificant decrease in jitterHowever, more complex queue management

Unified SchedulingAssume 3 types of traffic: guaranteed, predictive, best-effortScheduling: use WFQ in routerseach guaranteed flow gets its own queueother traffic aggregates in separate queuepredictive traffic classes: strict priority with FIFO+. Several classes separated by order of magnitude delay (sum of delays at each hop)best effort traffic gets lowest priority

Service InterfaceGuaranteed trafficspecifies rate (but not bucket size! Why?)if delay not good, ask for higher ratePredicted trafficspecifies (r, b)selects delay, loss, network assigns prioritypolicing at edges to drop or tag packets

ButDo we really need Integrated Services?Do we need to change the network service model?Or, do we just let applications adapt, and engineer the network for enough bandwidth?How do we even study this question?

Fundamental Design Issues for the InternetShenker95a

Key IdeasDo we need to extend the Internet service model (currently best effort)?Reservations, admission control, etc, orOverprovision and keep best effortHow do we even study this question?Simple model, very high level viewAsks fundamental questionsHelps guide the thinking for a very hard question

Model: Utility and EfficacyDoes the network make users happy?Define U(j) be the utility delivered to the jth userU(j) maps the networks performance to the users level of happinessFor example, higher bandwidth delivered to a video application (up to a point) makes the user happierSimilarly, lower delay delivered to application makes user happierGoal of network is to maximize the sum of all U(j)s (the efficacy, denoted by V)

More Bandwidth or New Service Model?In a best-effort network, can increase bandwidth to increase efficacyOr, for the same bandwidth, introduce new services matched to application needs and increase efficacy that wayKey question: whats the relative cost of adding bandwidth and adding new servicesShenker: always better to add new servicesMakes better use of available bandwidthBut cost of adding new services hard to estimate

Other ConsiderationsDo separate networks for different applications provide higher efficacy?No. A single network can always use leftover bandwidth to increase efficacyNote: increasing efficacy does not mean increasing everyones utilityService models must map application requirementsOtherwise, none of these arguments holds

Implicit V.S. Explicit Service RequestShould applications explicitly request service, or should the network determine service to deliver?Implicit doable if number of services is small and well known and stable (e.g., port number)Need to embed application knowledge inside the network (BAD!)Explicit supports larger variety of services but incentives needed so all do not request highest serviceApplications must know what they want!Pricing, accounting and billing: these are hardStable service model needed so apps know what to requestMajor coordination effort (imagine changing IP or Ethernet..)

Admission Control?Overload: a network is overloaded if by removing a flow would increase V even though there are fewer flowsIf V(n) does not continue to increase as n goes to infinity, then we either need admission control or over-provisioningBest Effort never overloads (or does it?)

Utility Curve ShapesBWUBWUBWUIf convex near origin, thenneed admission controlElasticHard real-timeDelay-adaptive

Over-provisioningWorks for normal users because need to overprovision by a small amountOver-provisioning for leading edge users is hard because these consume several orders of magnitude more than normal usersInternet will be provisioned to rarely block normal users, but will block leading edge users frequently

State of Integrated ServicesLots of work in the areaWe understand many of the problemsBut no commercial interest in the technologyToo complex?Can we build these schedulers in hardware?Need per-flow state for schedulingCan we do something simpler?

Differentiated Services (DiffServ)

Key IdeasTraffic classes instead of flowsForwarding behaviors instead of end-to-end service guaranteesTune applications to network services rather than network services to applicationsDiscrete v.s. continuous spaceNo resource reservationSomewhere between Best Effort and IntServ

Service DifferentiationAnalogy:airline service, first class, coach, various restrictions on coach as a function of paymentBest-effort expected to make up bulk of traffic, but revenue from first class important to economic base (will pay for more plentiful bandwidth overall)Not motivated by real-time but by economics and assurances

Types of ServicePremium service: (type P)admitted based on peak rateconservative, virtual wire servicesunused premium goes to best effort (subsidy!)Assured service: (type A)based on expected capacity usage profilestraffic unlikely to be dropped if user maintains profile. Out-of-profile traffic marked

Differences With Integrated ServicesNo need for reservations: just mark packetsPacket marking done at administrative boundaries before injecting packets into networkSignificant savings in signaling, much simpler overall

Service V.S. Forwarding TreatmentService: end-to-endForwarding treatment: hop-by-hop (in each router)Reasoning: various forwarding treatments can be used to construct same e2e serviceFree to implement treatments locally in various ways (buffer management and scheduling)Example: no-loss service implemented with priority queue (but needs admission control)

Service Level AgreementsMostly static or long-lived (but see later) Specification:Traffic profile (e.g., token bucket per class)Performance metrics (tput, delay, drop priority)Actions for non-conformant packetsAdditional marking/shaping

Premium ServiceUser sends within profile, network commits to delivery with requested profileSimple forwarding: classify packet in one of two queues, use priorityShaping at trust boundaries only, using token bucketSignaling, admission control may get more elaborate, but still not end-to-end

Premium Traffic Flowfirst hoprouterinternalrouterborderrouterhostborderrouterISPCompany AUnmarkedpacket flowPackets in premiumflows have bit setPremium packet flowrestricted to R bytes/sec

A Two-bit Differentiated Services Architecture for the InternetNichols99a

Premium V.S. Assured Forwarding BehaviorsPremium packets receive virtual circuit type of treatmentAppropriate for intolerant and rigid applicationsAssured packets receive better than best effort type of treatmentAppropriate for adaptive applications

2-bit Differentiated ServicePrecedence field encodes P & A type packetsP packets are BW limited, shaped and queued at higher priority than ordinary best effortA packets treated preferentially wrt dropping probability in the normal queueLeaf and border routers have input and output tasks - other routers just output

Leaf Router Input FunctionalityClearA & PbitsPacketclassifierMarker 1Marker NForwardingengineArrivingpacketBest effortFlow 1Flow NMarkers: service class, rate, permissible burst size

Marker Function in RoutersLeaf routers have traffic profiles - they classify packets based on packet headerIf no profile present, pass as best effortIf profile is for A:mark in-profile packets with A, forward others unmarkedIf profile is for P:delay out-of -profile packets to shape into profile

Markers to Implement Two Different ServicesWait fortokenSet P bitPacketinputPacketoutputDrop on overflow

Output Forwarding2 queues: P packets on higher priority queueLower priority queue implements RED In or Out scheme (RIO)At border routers profile meters test marked flows:drop P packets out of profileunmark A packets

Router Output Interface for Two-bit ArchitectureP-bit set?If A-bit setincr A_cntHigh-priority QLow-priority QIf A-bit setdecr A_cntRIO queuemanagementPackets outyesno

Red With In or Out (RIO)For Assured ServicesSimilar to RED, but with two separate probability curvesHas two classes, In and Out (of profile)Out class has lower Minthresh, so packets are dropped from this class firstAs avg queue length increases, in packets are dropped

RIO Drop ProbabilitiesMaxP1.0MinoutMininMaxinMaxoutP(drop)AvgLenMore drop probability curves (WRED)?

Border Router Input Interface Profile MetersArrivingpacketIs packetmarked?Tokenavailable?Tokenavailable?Clear A-bitDrop packetForwardingengineA setP settokentokenNot markednono

Per-hop Behaviors (PHBs)Define behavior of individual routers rather than end-to-end services - there may be much more services than behaviorsMultiple behaviors - need more than one bit in the headerSix bits from IP tos field are taken for Diffserv code points (DSCP)

Expedited Forwarding PHBEF packets are forwarded with minimal delay and loss (up to the capacity of the router)Rate limiting of EF packets achieved by configuring routers at edge of administrative domain

SignalingWhere?static (long-term):done out-of-banddynamic:from leaf to Bandwidth Broker and from BB in one domain to another BBHow?not clear, but maybe RSVP

Signaling: BBs

Diffserv V.S. Intserv SummaryResources to aggregated traffic, not flowsTraffic policing at the edges, class forwarding in the coreDefine forwarding behaviors, not servicesGuarantees by provisioning and SLAs, not reservationsFocus on single domain, not e2e (need BBs for e2e)

Open Issue: Inside or Outside the Network?Reservation based strategies can provide more varied QoS than feedback-based schemesWill this be the end of TCP? Highly unlikely. Applications are established, heterogeneous networks, etc.Diffserv is middle ground: no intelligence v.s. high intelligence with IntservWill we see a deployment? Jury is still out..

Currently weve talked about networks that providea single kind of service: best effort packet deliveryNo reason why packetized voice and video cant betransmitted over the netIn this section, we ask what it takes to support suchapplicationBasic assumption: many applications are elastic (I.e. they canadapt to network conditions and still be usable), othersneed some minimal level of resource commitmentsTwo examples: playback and interactivevery different requirements, explain that playbackclass of applications can do with some delay adaptationSome expectation that past behavior is anindicator of near future behavior- this is crucial (as we shall see)There is a delay bound, but it is loose:- actual delay is much lowerThis is key: we simply say: we can give you cheaperservice, if you can adapt and we try veryhard to maintain continuity of delay- this is the tricky design pointWe have designed for elastic applications: - TCP works wellThe entire class of real-time not yet consideredGive examples of each: intolerant would be interactiveor some kinds of incrementally coded video- tolerate would be playback; adapt to delay bybuffering packets etc.Rspec: end-to-end delay desiredVarious kinds of traffic descriptors: peak rate, average rateNotions of shaper/regulator, policerNotion of an LBAP; bounded within any interval of time tToken bucket as the mechanism to regulate an LBAPExplain that there is no unique token bucket- different parameters are possibleExplain using the exact mechanism as inCSZ paperExplain these carefullyExplain why this is: if you put it through a leakybucket filter, then traffic comes out at rater, and no queueing delay is encounteredeverywhereExplain this carefully: worth taking some timeto understandWFQ not suitable because bursts see much higherjitter: screws up the playback point adaptationFIFO: bursts dont see lower delay, so this is better- results in lower post facto jitterNeed to compensate for being delayed by bursts- mark arrival time and compensateTwo key ideas: isolation and sharing

Mention the notion of utilityNeed to extend service model because it isalways possible to increase utilitywith service differentiationAlso, can increase bandwidth to increaseutility; but in some cases, bandwidthincrease may need to be significantto achieve the same increase (hardto measure)Cant build separate networks, because leftover capacity can always be used toincrease utilityNote that increasing utility doesnt mean allusers winThis is the question of who chooses service fora flow- if explicit, incentives (pricing); usagebased charging etc.Talk about the condition for where you needoverprovisioning- convex: give intuition for thisElastic: never overloadedOthers you are, to varying degrees- key open question: can you quantifythe amount of overprovisioning neededto achieve the same utilityNote that the current definition of diffserv issomewhat more complicated- however, well just follow the nichols RFC

Two types of services:- virtual wire: peak rate provisioned very costly- expected capacity: rationale is similar to predictedservice: may work in some cases where rateis harder to bound: less expensive than virtualwire, accommodates statistical sharingDifferences with intserv- not motivated by real-time apps- no notion of continuous set of reservations- as we shall see, simple router behaviors- can achieve significant savingsBasic idea:- at ingress point, shape traffic- do the same at boundaries, just to conformto contracts- at ingress, police at the aggregate level- need some signaling to ensure that host canstart up a flow- notion of bandwidth brokers: can- be very simple initially, more complexlaterFigure out if flow needs to have premium/assured service- mark accordingly- how does traffic profile get into first hop router- static: any traffic between these hosts- more dynamic: need premium forIP telephony

RIO achieves assured services:key ideas: minth is lower, Pmax is higher and max is lowerstart of RED marking is earlier, end of RED marking is latermore aggressive markingCan extend this is more than two classes, with differentbehaviorsAt the ingress router- note that no packet classification happens- that is, things are determined by the aggregatedflows- policing and marking happens at ingress border routerAnother way to think about diffserv:- we have talked about it in the context ofthe actual services: like Premium- can decouple that and talk about per-hopbehaviors: router functionalityEF can be used to achieve premium service