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

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

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

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

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

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

8. Guaranteed Service policer Tx reshaper reshaper Rx Fluid model scheduling Fluid model scheduling Department of Computer Science

9. Tx Rx Fluid model scheduler with service rate, R. Tx Rx wire with bandwidth R 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 Department of Computer Science

10. traffic arrival traffic service backlog busy period time Relationship between service, traffic, loss and delay bounds bits Department of Computer Science

11. Tx Rx EDD scheduling jth packet, D=(M/r)*j+d 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 Department of Computer Science

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 (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” Department of Computer Science

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

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

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

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

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

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

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

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

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

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

23. Open Issues • Allocation of Diffserv resources. • Admission control algorithms for Diffserv. • How can we bridge the “islands” of IntServ/DiffServ. Department of Computer Science

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

25. Differentiated Service Architecture Diffserv region Tx PHB Rx meter Shaper/dropper To interiornodes classifier marker Department of Computer Science

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

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