1. IETF Integrated Services Model: Architecture and Scheduling Cheryl Pope Department of Computer Science University of Adelaide

2. IRCDepartment of Computer Science2 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. IRCDepartment of Computer Science3 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. IRCDepartment of Computer Science4 Integrated 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

5. IRCDepartment of Computer Science5 Traffic Specification To date, one general traffic specification parameter has been defined (RFC 2215): TOKEN_BUCKET_TSPEC Consists of: –float rtoken rate (bytes/sec) –float bbucket depth (bytes) –float ppeak rate(bytes/sec) –unsigned mminimum policed unit(bytes) –unsigned M maximum packet size(bytes) RSPEC consists of: Rrequested rate (bytes/sec) Sdelay slack (microseconds)

6. IRCDepartment of Computer Science6 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. IRCDepartment of Computer Science7 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

8. IRCDepartment of Computer Science8 Guaranteed Service Tx Rx policer reshaper Fluid model scheduling reshaper Fluid model scheduling

9. IRCDepartment of Computer Science9 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 Tx wire with bandwidth R

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

11. IRCDepartment of Computer Science11 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

12. IRCDepartment of Computer Science12 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”

13. IRCDepartment of Computer Science13 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. IRCDepartment of Computer Science14 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

15. IRCDepartment of Computer Science15 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. IRCDepartment of Computer Science16 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. IRCDepartment of Computer Science17 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. IRCDepartment of Computer Science18 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.

19. IRCDepartment of Computer Science19 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. IRCDepartment of Computer Science20 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. IRCDepartment of Computer Science21 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. IRCDepartment of Computer Science22 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.

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

24. IRCDepartment of Computer Science24 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. IRCDepartment of Computer Science25 Differentiated Service Architecture classifier Rx Tx Diffserv region marker meter Shaper/ dropper To interior nodes PHB

26. IRCDepartment of Computer Science26 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. IRCDepartment of Computer Science27 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?