QoS Architectures for Connectionless Networks Stewart Fallis [stewart@mirror.bt.co.uk] BT Advanced Communications Research

Outline Future network model A generic network model Current architectures ATM QoS Integrated Services Differentiated Services Evolving Differentiated Services ‘Soft’ QoS ‘Hard’ QoS Bounded Delay service Dynamic QoS Grade of service Generic QoS node Concluding comments

Need a Globally Accepted QoS Architecture Generic Network Model Core Network Real time Local Data Networks There is a distinct need for a ubiquitous QoS architecture whereby, the network is application independent. Therefore, traditional data, mobile and real time applications can co-exist on the same communications platform which supports degrees or shades of QoS. To propose a unified networking solution, then there must be coherence in the mechanisms employed with deliver such network functions, e.g. a generic QoS mechanism. Mobile Networks (real time & data) Need a Globally Accepted QoS Architecture

Current QoS Architectures ATM QoS Delay by design Classes: signalled via control Integrated Services Connection Oriented QoS Negotiable guaranteed end-to-end delay service Dynamic Delay Guarantees Zero packet loss Heavy weight signalling protocol Hard QoS Requires per-flow state in routers Pessimistic delay bound Differentiated Services Connectionless QoS Small set of aggregate classes: no per-flow information ‘Dumb’ core routers Integrated Services: It is connection oriented QoS It can deliver a quantifiable, guaranteed end-to-end delay with zero packet loss Relies on RSVP which may be too complex in it’s current implementation It is mainly Hard QoS Requires per-flow state in the network the delay bound of WFQ is pessemistic Differentiated Services: Connectionless QoS Uses aggregate set of classes ---> No need for per flow information Hence the Dumb core routers May not deliver a quantifiable low end-to-end delay bound Static QoS approach No feedback to users when a failure occurs QoS maybe too soft e.g. Premium service No-per flow separation Static: Subscription based No feedback from network when failure occurs

Evolving Differentiated Services What we really need is: Dynamic Bandwidth Allocation Per-flow state only at edge Signalling for hard QoS Low delay by design not negotiation Aggregate in core Not soft-state In order to provide a comprehensive QoS architecture, then there is a distinct need for the user to be able specify their QoS requirements to the underlying network. To avoid scalability issues, the complexity should be pushed out to the edges of the network and into the hosts. There should be some form of lightweight signalling mechanism for the Hard QoS class. There should be no soft state in the network. This provides an architecture that suppoprts both connectionless and connection oriented QoS Network would support both ‘Hard’ and ‘Soft’ QoS

Soft QoS: Olympic Service Ensures access to specified portion of o/p link bandwidth Host inserts pkt class Gold Profiler Scheduling Silver Bronze Random in packet drop aggressive out packet drop Polices pkt rate & marks those outside negotiated rate RIO Congestion control (RED IN and OUT packets) Buffer fill No drop Increasing load

Hard QoS: Bounded Delay Evolve Diffserv EF class Peak rate host shaping Limit Max Packet size Dimensioned buffer & bandwidth Guaranteed Delay bound + Simple FIFO queuing Overcomes Need For Per-Flow State

Hard QoS: Bounded Delay Core Network FIFO queuing for BD in core routers Host pk rate shaping Local Data Networks Complexity pushed to network edges & hosts

Bounded Delay: Delay Bound Host packetisation delay NW delay Packetisation Int-serv assumed best effort Network delays dominant Long timescales to ‘sort’ incoming packets Host packetisation delay NW delay Packetisation Bounded Delay assumes high speed core Packetisation delay dominant FIFO queuing is sufficient

Dynamic QoS Lightweight signalling User initiated Alternatively, communication can be via a bandwidth broker or could be future DNS? Lightweight signalling User initiated Simple bandwidth request Bandwidth Request Bandwidth request can involve only edge nodes, or depending on how onerous, all nodes.

Bounded Delay: Grade of Service Use CAC to restrict users Provides varying QoS from one “pool” of bandwidth C A Low user limit Medium user limit High user limit

Generic QoS Node Current IP architecture does not support connections! Switching engine Signalling Dest Address lookup Current IP architecture does not support connections!

Connection Oriented Routing Is this not simply MPLS? Dest Address lookup Label lookup Signalling Mapping QoS Architecture Switching engine CO routing does not affect the QoS Architecture

Conclusions Migration to control layer QoS is application, routing independent Common reservation method Common signalling method Range of QoS supported QoS architecture not dependant on other NW functions Work needs to be done on how and when to use these services