EECS 122: Introduction to Computer Networks Differentiated Services (DiffServ)

Computer Science Division Department of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA 94720-1776

EE122 F05

Problems with IntServ

Scalability: per-flow state, classification, etc. - Aggregation/encapsulation techniques can help - Can overprovision big links, per-flow ok on small links - Scalability can be fixed, but no second chance

Economic arrangements: - Need sophisticated settlements between ISPs - Right now, settlements are primitive (barter)

User charging mechanisms: need QoS pricing

EE122 F05 2

1 Differentiated Services (DiffServ)

Some traffic should get better treatment - Application requirements: interactive vs. bulk transfer - Economic arrangements: first-class versus coach

What kind of better service could you give? - Measured by drops, or delay (and drops)

How do you know which packets to give better service? - Bits in packet header

EE122 F05 3

DiffServ (cont’d)

Build around the concept of domain

Domain – a contiguous region of network under the same administrative ownership

Differentiate between edge and core routers

Edge routers - Perform per aggregate shaping or policing - Mark packets with a small number of bits; each bit encoding represents a class (subclass)

Core routers - Process packets based on packet marking

Far more scalable than Intserv, but provides weaker services

EE122 F05 4

2 Diffserv Architecture

Ingress routers - Police/shape traffic - Set Differentiated Service Code Point (DSCP) in Diffserv (DS) field

Core routers - Implement Per Hop Behavior (PHB) for each DSCP - Process packets based on DSCP

DS-1 DS-2

Ingress Ingress EgressEgress EgressEgress

Edge router Core router

EE122 F05 5

Traffic Limitations

Can’t give all traffic better service!

Must limit the amount of traffic that gets better service

Service Level Agreements (SLA) - Source agrees to limit amount of traffic in given class - Network agrees to give that traffic “better” service • For a price! - Economics play an important (fatal?) role in QoS

EE122 F05 6

3 “Expedited Forwarding”

Give packet minimal delay and loss service - E.g., put EF packets in high priority queue

To make this a true “absolute” service - All SLAs must sum to less than the link speed

EE122 F05 7

Is Delay the Problem?

With RED, most queues are small

Packets are dropped when queue starts to grow

Thus, delays are mostly speed-of-light latency

Service quality is mostly expressed by drop-rate

Want to give traffic different levels of dropping

EE122 F05 8

4 “Assured Forwarding”

Packets are all serviced in order - Makes TCP implementations perform well

But some packets can be marked as low-drop and others as high-drop - Think of it as priority levels for dropping

EE122 F05 9

Example

10% premium traffic, 90% ordinary traffic

Overall drop rate is 5%

Give premium traffic 0% drops; ordinary traffic a 5.55% drop rate

Large improvement in service for the small class of traffic without imposing much of a penalty on the other traffic - Count on SLAs to control premium traffic

EE122 F05 10

5 DiffServ “Code Points”

Use six of the ToS bits in IP packet header

Define various “code points” - Alternative classes of service (drop probability and assured forwarding)

Each code point defines a desired per-hop behavior - Description of the service the packet should get - Not a description of the router implementation of that service

EE122 F05 11

Differentiated Service (DS) Field

0 5 6 7 DS Filed

0 4 8 16 19 31 Version HLen TOS Length Identification Flags Fragment offset TTL Protocol Header checksum IP Source address header Destination address Data

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

EE122 F05 12

6 DiffServ Code Point Packet Headers

000 Routine 001 Priority 010 Immediate 011 Flash 100 Flash Override 101 Critical 110 Internetwork Control 111 Network Control

4 Classes (e.g., Business, Telecommuter, Residential) plus Low/Medium/High Drop Probability plus Expedited Forwarded (EF)

EE122 F05 13

Assured Service [Clark & Wroclawski ‘97]

Defined in terms of user profile, how much assured traffic is a user allowed to inject into the network

Network: provides a 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

EE122 F05 14

7 Assured Service

Large spatial granularity service

Theoretically, user profile is defined irrespective of destination - All other services we learnt are end-to-end, i.e., we know destination(s) apriori

This makes service very useful, but hard to provision (why ?) Traffic profile

Ingress

EE122 F05 15

Premium Service [Jacobson ’97]

Provides the abstraction of a virtual pipe between an ingress and an egress router

Network: guarantees that premium packets are not dropped and they experience low delay

User: does not send more than the size of the pipe - If it sends more, excess traffic is delayed, and dropped when buffer overflows

EE122 F05 16

8 Edge Router

Ingress

Traffic conditioner Class 1 Marked traffic Traffic conditioner Class 2 Data traffic Classifier Scheduler Best-effort

Per aggregate Classification (e.g., user) EE122 F05 17

Assumptions

Assume two bits - P-bit denotes premium traffic - A-bit denotes assured traffic

Traffic conditioner (TC) implement - Metering - Marking - Shaping

EE122 F05 18

9 TC Performing Metering/Marking

Used to implement Assured Service

In-profile traffic is marked: - A-bit is set in every packet

Out-of-profile (excess) traffic is unmarked - A-bit is cleared (if it was previously set) in every packet; this traffic treated as best-effort r bps User profile b bits (token bucket) assured traffic Set A-bit in-profile traffic Metering Clear A-bit out-of-profile traffic

EE122 F05 19

TC Performing Metering/Marking/Shaping

Used to implement Premium Service

In-profile traffic marked: - Set P-bit in each packet

Out-of-profile traffic is delayed , and when buffer overflows it is dropped r bps User profile b bits (token bucket)

premium traffic Metering/ Shaper/ in-profile traffic Set P-bit out-of-profile traffic (delayed and dropped) EE122 F05 20

10 Scheduler

Employed by both edge and core routers

For premium service – use strict priority, or weighted fair queuing (WFQ)

For assured service – use RIO (RED with In and Out) - Always drop OUT packets first • For OUT measure entire queue • For IN measure only in-profile queue Dropping probability 1 OUT IN

Average queue length

EE122 F05 21

Scheduler Example

Premium traffic sent at high priority

Assured and best-effort traffic pass through RIO and then sent at low priority

yes P-bit set? high priority

no yes A-bit set? no RIO low priority

EE122 F05 22

11 Control Path

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

EE122 F05 23

Example

Achieve end-to-end bandwidth guarantee

2 3

BBBB BBBB BBBB 7 5 1 9 6 4 8 profile profile profile receiver sender

EE122 F05 24

12 Comparison to Best-Effort and Intserv

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

EE122 F05 25

Summary

Diffserv more scalable than Intserv - Edge routers maintain per aggregate state - Core routers maintain state only for a few traffic classes

But, provides weaker services than Intserv, e.g., - Per aggregate bandwidth guarantees (premium service) vs. per flow bandwidth and delay guarantees

BB is not an entirely solved problem - Single point of failure - Handle only long term reservations (hours, days)

EE122 F05 26

13 Discussion: Factors Limiting QoS Deployment

Prevalence of overprovisioning - If all links are only at 40% utilization, why do you need QoS? - The inter-ISP links are not over provisioned

Primitive inter-ISP financial arrangements - QoS requires financial incentives to enforce tradeoffs - Current peering arrangements are not able to carry these incentives through in a meaningful way • Must agree on pricing and service • Currently agree on neither!

End-users not used to pricing/performance options EE122 F05 27

QoS Debates

Is overprovisioning enough? - If so, is this only because access links are slow? - What about Korea, Japan, and other countries with fast access links? - Disconnect: ISPs overprovision, users get bad service

Is differentiated services enough? - Can one really deliver reliable service just using relative priorities? - Is EF service a viable option?

It all depends on adaptability of applications

EE122 F05 28

14 EE122 F05 29

15