ietf integrated services model: architecture and scheduling cheryl pope department of computer...

IETF Integrated Services Model: Architecture and Scheduling

Cheryl PopeDepartment of Computer Science

University of Adelaide

IRC Department of Computer Science 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.


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


Integrated Service ArchitectureIntegrated Service Architecture

Tx

Rx

1) Tspec (sender traffic spec) ADSpec (services, possibly modified by routers)

2) Tspec (reservation traffic spec) RSpec (reservation service request) Service class


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)


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


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 <= M+min[pT, rT+b-M] : for all times T


Guaranteed ServiceGuaranteed Service

Tx

Rx

policerreshaper

Fluid model scheduling

reshaper

Fluid model scheduling


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. D=b/R

Fluid model scheduler with service rate, R.

Tx Rx

RxTxwire with bandwidth R


Relationship between service, traffic, loss and delay bounds

bits

time

traffic service

traffic arrival

busy period

backlog


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 {r=5, M=5, d=1} flow 2 {r=3, M=6, d=1} out link of r=10

EDD scheduling jth packet, D=(M/r)*j+d

Tx Rx


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 (AI*AR), VC is compared to a real-time clock (RTC). – If VC > RTC restrict flow– If VC < RTC, VC=RTC (prevent higher rate in subsequent

interval)• VC updates are packet based. AuxVC avoids saving

“credits”


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.


Guaranteed Service Bounds

• For fluid scheduling, an upper bound on delay is given by:

(b-M)/R * (p-R)/(p-r) + (M+Ctot)/R + Dtot for R<p

(M+Ctot)/R+Dtot for p<=R

• C - rate dependent error term

• D - rate independent error term

• From ADSPEC: M (path mtu, or service specific), C, D


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)


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


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.


Differentiated Service

• Integrated service provides QoS; but it has problems– It doesn’t 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.


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


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.


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.


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 hasn’t 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.


Open Issues

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



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


Differentiated Service Architecture

classifier

Rx

TxDiffserv region

marker

meter

Shaper/dropper

To interiornodes

PHB



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


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?

ietf integrated services model: architecture and scheduling cheryl pope department of computer...

Documents