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.