CS514: Intermediate
Course in Operating
Systems
Professor Ken Birman
Ben Atkin: TA
Lecture 19 Oct. 31
QoS via RSVP, Diffsrv
• Recall concept from last lecture
– Flow pre-specifies its goal
– Network reserves resources
– Goal is that if reservation is accepted,
properties will hold
• But as we saw, network can mess up
flow QoS properties
• Today: look at RSVP, Diffsrv:
proposals for implementing QoS
Reservé, s’ils vous plait
• Idea is that user will request
connection properties when
opening TCP session
– Rate of data link will carry
– Acceptable amount of jitter, loss
– Perhaps other properties
• Routers need to participate to
provide desired behavior
RSVP concept


Reserve 50
msgs/sec?



RSVP concept




Reserve 50
msgs/sec?

RSVP concept




Reserve 25
msgs/sec?
Reserve 50
msgs/sec?

RSVP concept


Reserve 25
msgs/sec?



RSVP concept
Reserve 25
msgs/sec?





Success!
RSVP concept


Success!



Router issues
• Router will need to set aside
resources on behalf of the flow
– Identify flow by (src,dst,ports)
• Router may also need a special
scheduling policy
• And must always reserve
enough bandwidth for possible
requests
For how long?
• Internet should be stateless,
oblivious to patterns of use
• RSVP suggests a new kind of
dependency on endpoint
information
• Developers responded with idea
of a “lease”
Leases
• A lease is a temporary
reservation
– Resources set to the side for this
user or application
– When lease expires, resources
return to the pool automatically
• RSVP operates using leases of a
few seconds at a time
Leases
• A lease needs to be renewed
before it expires
• Intention is that there should be
ample time to do so
• Will need to look at this more
carefully
Basic RSVP
assumptions
• Routes are assumed to be stable
– While routes are changing, all bets are off
– But in modern network, routes don’t
change very often
– Will mobility change this?
• Lease requests are assumed not to
experience packet loss
– Idea is that packet loss is intentional (RED)
– So we can treat lease requests as a special
category of operations and not drop them
RSVP protocol
• Request to create a connection
carries desired request profile
• Route is determined by the usual
Internet routing scheme
– But hop by hop, routers set aside
resources for this flow
– Router that can’t allocate resources
sends back a NAK
– Else endpoint sends an ACK
• If successful, lease will be refreshed
a little before it expires
RSVP is criticized
• Many practical problems
– What if a lease message is lost?
– How should router do packet
queuing to ensure that if the input
flow is within profile, the router
respects the desired QoS behavior
– How can ISV charge for resource
use?
What if lease req. lost?
• Issue is that leases must be
refreshed
• But messages can be lost in the
Internet
• If so, QoS properties will be lost
for this flow, perhaps without
warning
Packet queuing
• Internet is a store-and-forward network
• QoS is on a per-flow basis and is a
contract
– I’ll send 50 packets / sec
– You’ll forward them
• Unless routers maintain flow properties
hop by hop, the sender-side of the
contract can be violated
• We saw this in the last lecture
• Best queue mgt. scheme is unknown
ISV charge issue
• A typical network path might be
25 hops long
• Perhaps, 3 are road-runner, 10
are MCI, 7 are Pacific Bell, 5 are
within local area networks
– Who sets the prices for
connections with QoS properties?
– How are fees apportioned?
Pricing issues
• If MCI sets aside 250kb in each of 10
routers, shouldn’t it be paid more
than RR, with 250kb in only 3
routers?
• What if MCI routers are higher
performance machines where
resources cost more?
• How will billing work, mechanically?
Can MCI trust RR?
Security issues
• Denial of service attack
– User reserves lots of router space
– Perhaps uses fake charge info
• Causes resource exhaustion in
router
Wasted space
• Router wants resources to be
busy
• But will typical QoS user
actually need the worst case
bandwidth reserved?
• If not, resources are wasted
– Router would love to reuse them
– But can it safely do this?
Performance issue
• Mostly a worry in heavily loaded big
routers (“Internet backbone”)
• Must classify each packet based on
(src,src-port,dst,dst-port)
• This could be very costly!
• Worst case: QoS could become
common in which case load grows
as O(n2) in endpoints!
RSVP: Doomed?
• RSVP is an IETF standard now
• But seems unlikely to be
deployed in real networks
• These many issues are just too
hard to overcome
• Creates pressures for other
options
Diffsrv
• This proposal tries to offer
RSVP-like properties without
the drawbacks
• Focus is to
– Let routers operate as they do
now, hence no change in cost
model
– But must avoid classification
problem within the network
Diffsrv
• Proposal: use edge marking
– Pretend:
• we have reservation for desired resources
• reservation granted only if resources
available
– On packet admission, check to see if
packet matches user profile
– If not, or if no reservation, mark as “out
of profile” else mark as “in profile”
• Borrows one bit from IP header
Diffsrv concept
Profile
Checker
IN


IN

IN
IN

IN
out
IN

IN
RIO: RED with I/O bit
• Within the network, routers run a
modified version of RED
– But where RED discards any packet
– RIO discards out of profile packets first,
in profile packets have “higher priority”
• Idea is that we only degrade QoS
flows after running out of other flows
to degrade
– Revisit this in a minute…
How does Diffsrv
simulate leases?
• One idea:
– RSVP-like protocol but router
doesn’t really lease resources
– Instead it pretends to do so
• It tracks reservations but doesn’t
really set reserved resources to the
side
• Point is that it could have reserved
the resource
How to do leases?
• Another idea:
– We could have a central service to
handle reservations
– It watches routing tables hence
knows route packets will take
– Basically emulates this “abstract”
lease idea using a graph of
network resource uses and needs
Simulated Leases
Profile
Checker
IN


IN

IN
IN

IN
out
IN

IN
Resource Res.
Service
Issues with Diffsrv
• If network routes change, will
this invalidate the reservation?
– Yes! But who can tell?
• Should a RED policy apply to a
QoS connection?
• What about our old concern
about network dynamics?
Network flow dynamics
• Recall that network can be a
distorting influence on flows
• With Diffsrv, guarantee was based
on a stochastic picture
– This distortion could mean that load
surges occur where router sees clients
“out of profile” and yet all packets
marked as “in profile”!
– Guarantees of Diffsrv are probabilistic
QoS gotchas
• None of the proposals deals with
– How to pay ISVs
– Failure and dynamic route changes
– Distorted flow dynamics due to normal
route updates
– Multicast (needed for collaboration)
• As a result, all schemes give fairly
weak QoS guarantees
Other options?
• Leased lines
– Company can lease line equivalent
of a dedicated network link
– In effect: build your own Internet
• This is how Island Media works
– They offer a dedicated Internet
– But cost is high!
• Companies like Akamai use them
Other options?
• Run over telephone lines
– Common and cheap
– But capacity is tiny
• Multimode applications
– Idea is to glue telephony, Internet,
perhaps radio or other media
together to obtain desired
behavior
Emerging issues?
• Mobility is changing the picture
– Mobile users have dynamic routes
– They often will need QoS
• Leads to vision of a resourceaware world
– PDA tracks surroundings
– Adapts behavior based on
available QoS and loads
Emerging issues?
• Growth in multicast
– Multicast technology is taking off
– But QoS proposals all treat
multicast as secondary
– Issue arises mostly when dealing
with degradation of a flow
• If there are n processes downstream
from me, will a packet loss count as n
lost packets or just one?
Emerging issues?
• How to present QoS to end user
– Application is object oriented
– Should object interfaces include
some form of QoS contract?
• “I need x to operate correctly”
• “When given x I guarantee y”
– Some applications will have
multiple QoS domains of behavior
Example: video
• When streaming video we use
MPEG compression
• It produces
– Index frames
– One or more levels of difference
frames
• For best quality need all of them
Example: video
• Suppose that process
– Has limited bandwidth
– Wants to receive a video MPEG
stream
• How can it get just what it
needs?
Example: video
• Idea is to send each type of frame in
a separate stream
– Could be point to point or multicast
– Could even do special streams for
devices with small screens…
• Subscribe to those streams you can
afford to receive
• Very popular with multimedia
community!
– In multicast case lets receiver select
the quality; sender doesn’t need to know
Layered video streams
time
Index Frame
L1 Diff Frame
L0 Diff Frame
Index Frame
L0 Diff Frame
Index Frame
Streaming video (MPEG)
server
Layered video streams
time
Index Frame
L1 Diff Frame
L0 Diff Frame
Index Frame
L0 Diff Frame
Index Frame
Streaming video (MPEG)
server
Layered video streams
time
Index Frame
L1 Diff Frame
L0 Diff Frame
Sender emits multiple streams
Index Frame
L0 Diff Frame
Index Frame
Streaming video (MPEG)
server
Layered video streams
Low-power user subscribes
to just one stream… high power
user subscribes to multiple streams
Streaming video (MPEG)
server
Sender emits multiple streams
Issues?
• Receiving process might later move
into a better-connected environment
– So want a way to sense QoS properties
of network
– Could join and leave dynamically
• But a process is many objects
– All of them might need to reconfigure in
a coordinated manner
– Issue of synchronization looms large…
Summary
• Many proposals for QoS
– RSVP, Diffsrv, layered streams…
• None is terribly convincing
• None likely to emerge anytime soon
– Leased networks, e.g. Island Media or
Akamai probably most popular
– But costs very high to build such
networks
• QoS on the Internet would be worth
zillions! But how to work-around
Internet challenges?)