Quality of Service Frameworks Hamed Khanmirza Principles of Network University of Tehran

What is QoS? The capability to control traffic handling mechanisms in the network such that the network meets the service needs of certain applications and users subject to network policies. Applications –Elastic (delay-tolerant) Tolerate delays and losses Can adapt to congestion –Non-elastic (Real-Time) Needs some kind of guarantee from network QoS Parameters –Bandwidth –Latency –Jitter –Loss

Utility Curve Shapes BW U U U ElasticHard real-time Delay-adaptive

Integrated Services

Service characteristic Enhancing IP Service Model –Add QoS service classes –Explicit resource management at IP level –Per flow state maintained at routers which is used for admission control and scheduling set up by signaling protocol, users explicitly request their needs. This is done with RSVP protocol

Integrated Services Example Sender Receiver Achieve per-flow bandwidth and delay guarantees –Example: guarantee 1MBps and < 100 ms delay to a flow Path RSVP Message

Integrated Services Example Sender Receiver Allocate resources - perform per-flow admission control RESV RSVP Message

Integrated Services Example Sender Receiver Install per-flow state

Sender Receiver Install per flow state Integrated Services Example RESV RSVP Message

Integrated Services Example: Data Path Sender Receiver Per-flow classification

Integrated Services Example: Data Path Sender Receiver Per-flow buffer management

Integrated Services Example Sender Receiver Per-flow scheduling

Service Types Multiple service classes Service can be viewed as a contract between network and communication client –end-to-end service –other service scopes possible Three defined services –Best-Effort for (best-effort or elastic) –Guaranteed Service for hard real-time (“Real-Time applications”) –Controlled Load for soft real-time (“tolerant” applications)

Differentiated Services

What is the Problem? Goal: providing support for wide variety of applications: –Interactive TV, IP telephony, on-line gamming (distributed simulations), VPNs, etc Problem: –Best-effort cannot do it –Intserv can support all these applications, but Too complex Not scalable –Queuing & scheduling –Classification speed –Hardware Restriction DiffServ aims at providing QoS with simple mechanisms so that it scales and can be deployed. –push the complexity to the “edges” of the network. –Provide weaker guarantee

DiffServ Architecture Ingress routers (Edge Routers) –Perform per aggregate shaping or policing (Behavior Aggregate) –Mark packets with Code Points, each CP represent a Class of Service (DSCP DiffServ Code Point) Core routers –Implement Per Hop Behavior (PHB) for each DSCP –Process packets based on DSCP Ingress Egress Ingress Egress DS-1 DS-2 Edge router Core router

Differentiated Service (DS) Field VersionHLen TOSLength Identification Fragment offset Flags Source address Destination address TTLProtocolHeader checksum Data IP header DS filed reuse the first 6 bits from the former Type of Service (TOS) byte The other two bits are proposed to be used by ECN DS Filed

Per Hop Behavior (PHB) Define behavior of individual routers rather than end-to-end services Two PHBs –Assured Forwarding (AF, A type) –Expedited Forwarding (EF, P type) –Plus, best-effort service!

EF PHB (Premium) Provides the abstraction of a “virtual pipe” between an ingress and an egress router Network: –No loss –low delay & jitter User: –Send traffic based on SLA –Excess traffic is delayed, and dropped when buffer overflows Signaling, admission control may get more elaborate in future (DiffServ/RSVP)

Assured Forwarding PHB Possible service: –strong assurance for traffic within profile –Out-of-profile traffic will be marked as lower class (i.e. BE) Network: –lower loss rate than best-effort –In case of congestion best-effort packets are dropped first User: sends no more assured traffic than its profile –If it sends more, the excess traffic is converted to best-effort IETF defines AF as (RFC 2477) –4 classes –Each with 3 drop precedence –Order of packets must be preserved

Provisioning & Configuration To provide network QoS, some configuration and provisioning is required Provisioning: –Static and long-term management tasks Enhancing network equipment Interface definition Link speed and BW Configuration: –Dynamic and short-term tasks Direct manipulation of traffic handling mechanisms

Service Level Agreement & Policy Agreements/service provided within a domain –Service Level Agreement (SLA) with ISP Policy –A high level description of the quality and efficiency objectives to be met by the network –Policy is set by SLA

Example of an SLA Traffic submitted by customer c1 and marked with DSCP = EF and destination address in subnet 2.x.x.x and conforming to profile p1 Will be delivered to egress point B with latency not exceeding 100ms and a drop-probability less than 0.1% Traffic submitted by customer c1 and marked with DSCP = EF and destination address in subnet 2.x.x.x and not conforming to profile p1 Will be discarded

Example of an SLA Traffic submitted by customer c1 and marked with DSCP = EF and destination address in subnet 3.x.x.x and conforming to profile p2 Will be delivered to egress point C with latency not exceeding 100ms and a drop-probability less than 0.1% Traffic submitted by customer c1 and marked with DSCP = EF and destination address in subnet 3.x.x.x and not conforming to profile p2 Will be discarded

Example of an SLA Traffic submitted by customer c1 and marked with DSCP = EF and destination address not in subnet 2.x.x.x and destination address not in subnet 3.x.x.x Will be discarded Traffic submitted by customer c1 and not marked with DSCP = EF Will be delivered with best-effort service P1: Conforming traffic must not exceed 64kbps over any 5msec interval P2: Conforming traffic must not exceed 128kbps over any 2.5msec interval

Pushed vs. Signaled

Components of Policy System Functional Layers No physical

Distributed Data Store - Directory

Interior Provisioning

Assured Service Large spatial granularity service Theoretically, user profile is defined irrespective of destination This makes service very useful, but hard to provision –Over provision? Ingress Traffic profile

Multicast Problems in DiffServ Multicast –Problem Dynamic trees –Solutions Different DSCP Some determined tree structure Remarking and shaping at boundaries

DiffServ Implementations Two important proposals –RIO Mechanism (1 service) –The Scalable Share Differentiation architecture (SSD) –Two-Bit architecture –RFC (2475)

Two-Bit Architecture Proposes three different levels of service: –Premium Service. –Assured Service. –Best Effort Service. Two-bit architecture: –Packets get differentiated by two bits in their header. –Premium bit (P-bit) –Assured Service bit (A-bit)

Leaf Router Input Functionality MF Packet classifier MF Packet classifier Marker 1 Marker N Forwarding engine Forwarding engine Arriving packet Best effort Flow 1 Flow N classify packets based on packet header Clear A&P bits Clear A&P bits

Markers in Leaf Routers Wait for token Wait for token Set P bit Packet input Packet output Test if token Test if token Set A bit token No token Packet input Packet output Drop on overflow RIO is applied here

Red with In or Out (RIO) Similar to RED With two separate probability curves –In (of profile) –Out (of profile) “Out” class has –lower Min thresh, so packets are dropped from this class first –Based on queue length of all packets “In” Class –As avg queue length increases, “in” packets are also dropped –Based on queue length of only “in” packets OUTIN Average queue length 1 Dropping probability

Output Forwarding 2 queues: –High Priority: EF packets –Lower priority queue implements RED “In or Out” scheme (RIO) Usually scheduling scheme is “Strict Priority” P bit set? If A bit set incr a_cnt If A bit set incr a_cnt High-priority Q Low-priority Q If A bit set decr in_cnt If A bit set decr in_cnt RIO queue management RIO queue management Send Packet EF AF

Intra Domain Behavior Each domain is assigned a Bandwidth Broker (BB) –Usually, used to perform ingress-egress bandwidth allocation BB is responsible to perform admission control in the entire domain BB not easy to implement –Require complete knowledge about domain –Single point of failure, may be performance bottleneck –Designing BB still a research problem

Example Achieve end-to-end bandwidth guarantee BB sender receiver 8 profile 6 4

RFC 2475: Overall Architecture Classifiers: 1.Multifield Classifier (MF) 2.Behavior Aggregate Classifier (BA)

Traffic Conditioning Schedulers –Work-conserving –Non-work-conserving Traffic conditioning uses Non-work-conserving ones Implementations –Leaky Bucket –Token Bucket –Hybrid approaches Leaky-Token Bucket Dual Token Bucket

Leaky Bucket Smoothes traffic and generates constant rate b bits r b/s

Token Bucket Filter Described by 2 parameters: –Token rate r: rate of tokens placed in the bucket –Bucket depth b: capacity of the bucket Operation: –Tokens are placed in bucket at rate r –If bucket fills, tokens are discarded –Sending a packet of size P uses P tokens –If bucket has P tokens, packet sent at max rate, else must wait for tokens to accumulate

Token Bucket Operation Tokens Packet Overflow Tokens Packet Enough tokens  packet goes through, tokens removed Not enough tokens  wait for tokens to accumulate

Token Bucket On the long run, rate is limited to r On the short run, a burst of size b can be sent Token Bucket 3 possible uses –Shaping Delay pkts from entering net (shaping) –Policing Drop pkts that arrive without tokens –Metering (Marking) Let all pkts pass through, mark ones without tokens

Comparison Service Service Scope Complexity Scalability Connectivity No isolation No guarantees End-to-end No set-up Highly scalable (nodes maintain only routing state) Best-Effort Per aggregation isolation Per aggregation guarantee Domain Long term setup Scalable (edge routers maintains per aggregate state; core routers per class state) Diffserv Per flow isolation Per flow guarantee End-to-end Per flow setup Not scalable (each router maintains per flow state) Intserv