Architectures for Quality of Service (QoS) in the Internet

1
Architectures for Quality of Service (QoS) in the
Internet

• Cheryl Pope
• Department of Computer Science
• University of Adelaide

2
QoS What is it Why would we want it?

• Many applications are sensitive to the effects of
  delay, jitter and packet loss.
• The existing Internet architecture provides a
  best effort service.
• All traffic is treated equally (FIFO queuing).
  Currently there is no mechanism for
  distinguishing between delay sensitive and best
  effort traffic.
• IPv4 TOS is not widely implemented.

3
Options for a QoS Internet

• ATM - designed from the start to support QoS
• Must convince everyone to change existing
  infrastructure or build a second real-time
  Internet. (This isnt happening.)
• IP/ATM still leaves the IP applications with no
  mechanism for requesting QoS from TCP/IP
• Overprovisioning
• If the QoS provided is sufficient for all
  applications, then no further action is required
• What about Napster, Quake, what is next?

4
Controlling Congestion

• The only delay and loss that a router can control
  is that due to congestion.
• Routers in the existing Internet can currently
  influence congestion by
• Routing to minimise delay (balancing load)
• Discarding packets (TCP back off)
• This penalises elastic traffic. Even is some of
  the competing traffic doesnt have tight delay
  requirements.

5
Integrated Service Architecture

• Integrated Service (IntServ) expands congestion
  control to include reservation of resources
• Signalling through Resource Reservation Protocol
  (RSVP)
• Specification of traffic characteristics and QoS
• Admission control
• Policing and shaping of traffic
• Scheduling of flow packets

6
Integrated Service Architecture
1) Tspec (sender traffic spec) ADSpec
(services, possibly modified by routers)
Tx
Rx
2) Tspec (reservation traffic spec) RSpec
(reservation service request) Service class
7
Service Categories

• Guaranteed
• Upper bound on queuing delay, assured data rate,
  no loss
• Hard real-time applications
• Controlled Load
• Approximates best-effort service under unloaded
  conditions
• Adaptive real-time applications
• Best effort

8
Guaranteed Service
policer
Tx
reshaper
Rx
Fluid model scheduling
9
Differentiated Service

• Integrated service provides QoS but it has
  problems
• It doesnt scale. The routers would have to
  maintain state on every flow passing through
  them.
• Heterogeneous networks may not provide particular
  QoS controls or even RSVP.
• Differentiated service (DiffServ) aims to offer
  QoS to aggregated flows.

10
Differentiated Service

• DiffServ defines Differentiated Service Code
  Points (DSCP) - IPv4 TOS, IPv6 Traffic Class
• All traffic in one DSCP is treated the same.
• Per hop behaviour (PHB) is determined by DSCP of
  packet.
• Service Level Agreements are with customers
  (possibly other diffserv clouds) not flows.

11
Differentiated Service Architecture
Diffserv region
Tx
PHB
Rx
meter
Shaper/dropper
To interiornodes
classifier
marker
12
Differentiated Service

• Resource allocation
• Bandwidth broker global view of resources.
• Static provisioning may give poor service to
  flows.
• Signalling use of RSVP to allocate resources.
• Defined Per Hop Behaviours
• Expedited Forwarding near constant
  delay/throughput
• Virtual Wire aggregate
• Assured Forwarding provides low loss probability
  for compliant traffic. Guarantees ordering of
  packets in a given AF class.

13
Combining IntServ DiffServ

• IntServ provides fine grain control and handles
  dynamic allocation of resources to flows.
• DiffServ provides course grain control of flows
  through their aggregates.
• The two together can be combined to provide
  scalable end to end Integrated service, using a
  DiffServ region as a single element.
• Controlled Load can be implemented over Assured
  Forwarding PHB
• Guaranteed can be implemented over Expedited
  Forwarding PHB

14
Multicasting

• Multicasting is both a main argument for
  reservations and one of the main problems for
  IntServ/DiffServ
• Muticast can generate a large amount of
  potentially unnecessary traffic.
• Number and QoS requirements of receivers can
  change dynamically, without changing incoming
  traffic.
• Provision based on all possible routers that
  could be part of a multicast?
• Receivers may have different QoS requirements.
  How does DiffServ manage this with a single PHB
  at the boundary?

15
Current State

• RSVP and the queuing mechanisms to support
  IntServ are available in IPv6 distributions.
• IPv6 is implemented in Solaris, Windows 2K,
  Linux, BSD.
• DiffServ projects are currently being run under
  Internet2 and CAnet2.

16
Open Issues

• Existing proposals for Intserv/Diffserv control
  latency but not jitter. Delays are pessimistic
  so predicted jitter can be large.
• Flows are one-way. No symmetric architecture
  exists yet.
• Multicast causes problems for both Intserv
  Diffserv, which base expected internal loads on
  ingress/egress pairs of traffic.
• Fault-tolerance and recovery of flows hasnt been
  touched on.
• Flow resource requirements are pessimistic.
  Aggregation of Tspecs is also pessimistic leading
  to even more pessimistic resource allocations.
  Probabilistic mechanisms need more study.

17
Open Issues

• Allocation of Diffserv resources.
• Admission control algorithms for Diffserv.
• How can we bridge the islands of
  IntServ/DiffServ.