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. University of Adelaide, Computer Science

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 isn’t 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? University of Adelaide, Computer Science

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 doesn’t have tight delay requirements. University of Adelaide, Computer Science

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 University of Adelaide, Computer Science

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 University of Adelaide, Computer Science

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 University of Adelaide, Computer Science

8. Guaranteed Service policer Tx reshaper Rx Fluid model scheduling University of Adelaide, Computer Science

9. 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. University of Adelaide, Computer Science

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. University of Adelaide, Computer Science

11. Differentiated Service Architecture Diffserv region Tx PHB Rx meter Shaper/dropper To interiornodes classifier marker University of Adelaide, Computer Science

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. University of Adelaide, Computer Science

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 University of Adelaide, Computer Science

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? University of Adelaide, Computer Science

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. University of Adelaide, Computer Science

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 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. University of Adelaide, Computer Science

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