IETF Integrated Services Model: Architecture and Scheduling

1
IETF Integrated Services Model Architecture and
Scheduling

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

2
Integrated Services - motivation

• 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.
• Aim of IntServ WG to specify the enhanced
  services needed in the Internet service model to
  support the integration of real-time and
  classical data traffic.

3
Integrated Services Architecture

• Integrated Services (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

4
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
5
Traffic Specification

• To date, one general traffic specification
  parameter has been defined (RFC 2215)
  TOKEN_BUCKET_TSPEC
• Consists of
• float r token rate (bytes/sec)
• float b bucket depth (bytes)
• float p peak rate (bytes/sec)
• unsigned m minimum policed unit (bytes)
• unsigned M maximum packet size (bytes)
• RSPEC consists of R requested rate (bytes/sec)
• S delay slack (microseconds)

6
Service Categories

• Guaranteed
• Mathematically provable 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

7
Traffic distortion

• Traffic policing monitors that traffic at the
  source adheres to its Tspec.
• Traffic that is well behaved at the network edges
  can still become distorted within the network.
• Reshaping is typically used to correct this
  distortion.
• Ensure that data sent lt MminpT, rTb-M
  for all times T

8
Guaranteed Service
policer
Tx
reshaper
reshaper
Rx
Fluid model scheduling
Fluid model scheduling
9
Fluid Model Scheduling

• If an element approximates the fluid model then
  the service received will be the same as a wire
  with bandwidth equal to the service rate.
• Aim is to isolate traffic flows from each other.
  Db/R

10
Relationship between service, traffic, loss and
delay bounds

• bits

11
EDD(Ferrari, 1990)

• Based on EDF scheduling from real-time systems.
• Deadline, D, based on guaranteed delay bound, d
  and expected arrival time of packet.
• Packets placed in priority queue sorted by D
• Requires that both link and scheduler are not
  saturated.
• Consider 2 flows flow 1 r5, M5, d1 flow 2
  r3, M6, d1 out link of r10

12
Virtual Clock(L. Zhang, 1991)

• Scheduling of packets based on when packets would
  have been sent if TDM were used.
• Timers VC (flow monitoring) and auxVC (packet
  scheduling)
• On packet arrival both timers are advanced to
  next packet eligibility time.
• After a set number of packets (AIAR), VC is
  compared to a real-time clock (RTC).
• If VC gt RTC restrict flow
• If VC lt RTC, VCRTC (prevent higher rate in
  subsequent interval)
• VC updates are packet based. AuxVC avoids saving
  credits

13
Packet by packet generalised processor sharing
(PGPS)(Parekh, 1994)

• Based on weighted fair queuing (weight
  proportional to R)
• Priority queue (similar to EDD and VC) ordered by
  time the packet would have been scheduled had bit
  by bit fair queuing been used.

14
Guaranteed Service Bounds

• For fluid scheduling, an upper bound on delay is
  given by
• (b-M)/R (p-R)/(p-r) (MCtot)/R Dtot for
  Rltp
• (MCtot)/RDtot for pltR
• C - rate dependent error term
• D - rate independent error term
• From ADSPEC M (path mtu, or service specific),
  C, D

15
Limitations

• Guaranteed service only bounds the maximum
  queuing delay.
• None of the proposed schedulers provide bounded
  jitter.
• All are work conserving models so a minimum
  queuing delay of 0 is possible.
• Actual delays are likely to be significantly less
  than the worst case maximum, so nominal jitter
  can be large.
• Scheduling algorithms exist that do control
  jitter (jitter-EDD, Stop and Go)

16
Controlled Load

• Aim Behaviour similar to best effort on an
  unloaded network, regardless of actual network
  load (in Tspec traffic)
• No specific delay bounds
• Tspecs can exceed network element resources
• Out of Tspec traffic becomes best effort
  (separate from elastic traffic!)
• Possible implementations
• Fluid models (isolation of traffic in traffic
  classes)
• Measurement based
• Probabilistic

17
Routing

• Integrated Services (CL GS) requires fixed
  routing.
• Possibly handled by
• Pre-configuration
• Source based routing
• (Multi-protocol Label Switching) MPLS
• Recovery of IntServ flows from element/link
  failures is not well studied, yet.

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

19
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

20
Summary

• Integrated Service provides applications with
  guaranteed delay bounds or performance similar to
  an unloaded link.
• Several scheduling algorithms exist.
• RSVP can be used to support signalling of traffic
  and service requirements for admission control
• MPLS can support fixed path routing (more likely
  at aggregate than per flow)
• Differentiated Service provides scalable service
  across network regions
• Research is still needed on bridging the gap
  between session based flows and aggregated flows.

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

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

23
Open Issues

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

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

25
Differentiated Service Architecture
Diffserv region
Tx
PHB
Rx
meter
Shaper/dropper
To interiornodes
classifier
marker
26
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.

27
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?