Integrated and Differentiated Services

Christos Papadopoulos

CS551 – Fall 2002

(http://netweb.usc.edu/cs551/)

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 (200 - 300ms) 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-adaptiveadaptive Non-adaptive

Delayadaptive

Rateadaptive

Rateadaptive

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

tokens

Packet

Enough tokenspacket goes through,tokens removed

Not enoughtokens - wait fortokens toaccumulate

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

1

2

1 2 3

Flow A

Flow BFlow 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

BW

U

BW

U If convex near origin, thenneed admission control

Elastic Hard 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 hoprouter

internalrouter

borderrouter

host

borderrouter

ISP

Company A

Unmarkedpacket flow

Packets in premiumflows have bit set

Premium packet flowrestricted to R bytes/sec

A Two-bit Differentiated Services Architecture for the

InternetNichols99a

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

ClearA & P

bits

Packetclassifier

Marker 1

Marker N

Forwardingengine

Arrivingpacket Best effort

Flow

1Fl

ow 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 fortoken

Set P bitPacketinput

Packetoutput

Test iftoken Set A bit

token

No token

Packetinput

Packetoutput

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 setincr A_cnt

High-priority Q

Low-priority Q

If A-bit setdecr A_cnt

RIO queuemanagement

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

Minout Minin MaxinMaxout

P(drop)

AvgLen

More drop probability curves (WRED)?

Border Router Input Interface Profile Meters

Arrivingpacket

Is packetmarked?

Tokenavailable?

Tokenavailable?

Clear A-bit

Drop packet

Forwardingengine

A set

P set

token

token

Not marked

no

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..