Integrated and Differentiated Services Christos Papadopoulos CS551 – Fall 2002 (

Motivation Some applications require minimum level of network performance Some less elastic applications are not able to adapt to changes in bandwidth and delay –bandwidth below which video and audio are not intelligible –internet telephones, teleconferencing with high delay ( ms) impair human interaction

The Problem

A Class of Real-time Applications Playback applications –set a playback point in the future –buffer packets until playback point Features that you can leverage –early packet arrival ok –performance improves with lower delay –need absolute or statistical bound on delay –tolerate some loss

Rigid V.S. Adaptive Applications Two classes of playback applications –Rigid/adaptive –Tolerant/intolerant The distinction here is whether the application would tolerate interruptions Rigid applications –Set fixed playback point (a priori bound) Adaptive applications –Adapt playback point (de facto bound) –A priori bound > de facto bound

Adaptive Applications Gamble that network conditions will be the same now as in the past Are prepared to deal with errors in their estimate Will in general have an earlier playback point than rigid applications Experience has shown that they can be built (e.g., vat, various adaptive video apps)

Real-time Applications Real-Time Applications Loss, delay tolerant Intolerant Non-adaptiveadaptiveNon-adaptive Delay adaptive Rate adaptive Rate adaptive

Architectural Components Commitments made by network –type of service the network provides Service interface –characterization of source traffic –characterization of QoS network will deliver Packet scheduling –algorithms, information in headers Admission control –policing

Types of Network Service Commitments Guaranteed service –For intolerant and rigid applications Predicted service –For tolerant and adaptive applications Applications gamble, why not the network? –Two components: If conditions do not change, commit to current service If conditions change, take steps to deliver consistent performance (help apps set playback point by minimizing post facto delay bounds)

Service Interface: Flowspecs Tspec: describes the flow’s traffic characteristics Rspec: describes the service requested from the network

Token Bucket Filter Described by 2 parameters: –token rate r: rate of tokens placed in the bucket –bucket depth B: capacity of the bucket Operation: –tokens are placed in bucket at rate r –if bucket fills, tokens are discarded –sending a packet of size P uses P tokens –if bucket has P tokens, packet sent at max rate, else must wait for tokens to accumulate

Token Bucket Operation tokens Packet overflow tokens Packet Enough tokens packet goes through, tokens removed Not enough tokens - wait for tokens to accumulate

Token Bucket Characteristics In the long run, rate is limited to r In the short run, a burst of size B can be sent Amount of traffic entering at interval T is bounded by: –traffic = B + r*T Information useful to admission algorithm

Token Bucket Specs BW Time Flow A Flow B Flow A: r = 1 MBps, B=1 byte Flow B: r = 1 MBps, B=1MB

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

Guarantee Proven by Parekh Suppose a flow –gets a rate r at every router in network –and all routers in network do WFQ –… and the corresponding token bucket burst size is b Then, in any arbitrary topology –Cumulative queuing delay Di suffered by flow i has upper bound b/r –even if the switch is shared with unshaped flows This result holds for a fluid flow approximation –Additional terms to the delay bound with a packet approximation Intuition: –Imagine flow i shaped with token bucket, –… then all delay is incurred at entrance to network

Scheduling Guaranteed Traffic Use token bucket filter to characterize traffic Use WFQ at the routers Parekh’s bound for worst case delay So why not only have guaranteed and best effort –Delays can be high unless one reserves a rate r which is higher than the average rate –Network can then be significantly underutilized

Predicted Service WFQ not suitable –Provides isolation, but the delay is not shared –… and can self-impose jitter in post facto delay –FIFO with multiple priority levels might work But jitter can increase in a multi-hop case So, use FIFO+ –At each hop: measure average delay for class at that router –For each packet: compute difference of average delay and delay of that packet in queue –Add/subtract difference in packet header

Predicted Service: FIFO+ Simulation Simulation shows: –slight increase in delay and jitter for short paths –slight decrease in mean delay –significant decrease in jitter However, more complex queue management

Unified Scheduling Assume 3 types of traffic: guaranteed, predictive, best-effort Scheduling: use WFQ in routers –each guaranteed flow gets its own queue –other traffic aggregates in separate queue predictive 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 Interface Guaranteed traffic –specifies rate (but not bucket size! Why?) –if delay not good, ask for higher rate Predicted traffic –specifies (r, b) –selects delay, loss, network assigns priority –policing at edges to drop or tag packets

But… Do 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 Internet Shenker95a

Key Ideas Do we need to extend the Internet service model (currently best effort)? –Reservations, admission control, etc, or –Overprovision and keep best effort How do we even study this question? Simple model, very high level view –Asks fundamental questions –Helps guide the thinking for a very hard question

Model: Utility and Efficacy Does the network make users happy? Define U(j) be the utility delivered to the jth user –U(j) maps the network’s performance to the user’s level of happiness –For example, higher bandwidth delivered to a video application (up to a point) makes the user happier –Similarly, lower delay delivered to application makes user happier Goal 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 efficacy Or, for the same bandwidth, introduce new services matched to application needs –… and increase efficacy that way Key question: what’s the relative cost of adding bandwidth and adding new services –Shenker: always better to add new services Makes better use of available bandwidth But cost of adding new services hard to estimate

Other Considerations Do separate networks for different applications provide higher efficacy? –No. A single network can always use leftover bandwidth to increase efficacy Note: increasing efficacy does not mean increasing everyone’s utility Service models must map application requirements –Otherwise, none of these arguments holds

Implicit V.S. Explicit Service Request Should 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 service –Applications must know what they want! –Pricing, accounting and billing: these are hard Stable service model needed so apps know what to request –Major 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 flows If V(n) does not continue to increase as n goes to infinity, then we either need admission control or over-provisioning Best Effort never overloads (or does it?)

Utility Curve Shapes BW U U U If convex near origin, then need admission control ElasticHard real-time Delay-adaptive

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

State of Integrated Services Lots of work in the area We understand many of the problems –But no commercial interest in the technology –Too complex? Can we build these schedulers in hardware? Need per-flow state for scheduling Can we do something simpler?

Differentiated Services (DiffServ)

Key Ideas Traffic classes instead of flows Forwarding behaviors instead of end-to-end service guarantees –Tune applications to network services rather than network services to applications –Discrete v.s. continuous space No resource reservation Somewhere between Best Effort and IntServ

Service Differentiation Analogy: –airline service, first class, coach, various restrictions on coach as a function of payment Best-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 Service Premium service: (type P) –admitted based on peak rate –conservative, virtual wire services –unused premium goes to best effort (subsidy!) Assured service: (type A) –based on expected capacity usage profiles –traffic unlikely to be dropped if user maintains profile. Out-of-profile traffic marked

Differences With Integrated Services No need for reservations: just mark packets Packet marking done at administrative boundaries before injecting packets into network Significant savings in signaling, much simpler overall

Service V.S. Forwarding Treatment Service: end-to-end Forwarding treatment: hop-by-hop (in each router) –Reasoning: various forwarding treatments can be used to construct same e2e service –Free 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 Agreements Mostly 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 packets –Additional marking/shaping

Premium Service User sends within profile, network commits to delivery with requested profile Simple forwarding: classify packet in one of two queues, use priority Shaping at trust boundaries only, using token bucket Signaling, admission control may get more elaborate, but still not end-to-end

Premium Traffic Flow first hop router internal router border router host border router ISP Company A Unmarked packet flow Packets in premium flows have bit set Premium packet flow restricted to R bytes/sec

A Two-bit Differentiated Services Architecture for the Internet Nichols99a

Premium V.S. Assured Forwarding Behaviors Premium packets receive virtual circuit type of treatment –Appropriate for intolerant and rigid applications Assured packets receive “better than best effort” type of treatment –Appropriate for adaptive applications

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

Leaf Router Input Functionality Clear A & P bits Packet classifier Marker 1 Marker N Forwarding engine Arriving packet Best effort Flow 1 Flow N Markers: service class, rate, permissible burst size

Marker Function in Routers Leaf routers have traffic profiles - they classify packets based on packet header If no profile present, pass as best effort If profile is for A: –mark in-profile packets with A, forward others unmarked If profile is for P: –delay out-of -profile packets to shape into profile

Markers to Implement Two Different Services Wait for token Set P bit Packet input Packet output Test if token Set A bit token No token Packet input Packet output Drop on overflow

Output Forwarding 2 queues: P packets on higher priority queue Lower priority queue implements RED “In or Out” scheme (RIO) At border routers profile meters test marked flows: –drop P packets out of profile –unmark A packets

Router Output Interface for Two-bit Architecture P-bit set? If A-bit set incr A_cnt High-priority Q Low-priority Q If A-bit set decr A_cnt RIO queue management Packets out yes no

Red With In or Out (RIO) For Assured Services Similar to RED, but with two separate probability curves Has two classes, “In” and “Out” (of profile) “Out” class has lower Minthresh, so packets are dropped from this class first As avg queue length increases, “in” packets are dropped

RIO Drop Probabilities MaxP 1.0 Min out Min in Max in Max out P(drop) AvgLen More drop probability curves (WRED)?

Border Router Input Interface Profile Meters Arriving packet Is packet marked? Token available? Token available? Clear A-bit Drop packet Forwarding engine A set P set token Not marked no

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

Expedited Forwarding PHB EF 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

Signaling Where? –static (long-term): done out-of-band –dynamic: from leaf to Bandwidth Broker and from BB in one domain to another BB How? –not clear, but maybe RSVP

Signaling: BBs

Diffserv V.S. Intserv Summary Resources to aggregated traffic, not flows Traffic policing at the edges, class forwarding in the core Define forwarding behaviors, not services Guarantees by provisioning and SLAs, not reservations Focus 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 schemes Will 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 Intserv Will we see a deployment? Jury is still out..