integrated and differentiated services christos papadopoulos cs551 – fall 2002 (
TRANSCRIPT
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
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?
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?
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
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
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..