Differential Services

1. Differential Services Services and Mechanisms ANDREW T. CAMPBELL Dept. of Electrical Engineering Columbia University http://comet.columbia.edu/campbell campbell@comet.columbia.edu LECTURE 11 24 November, 1998

2. Review of the last week • Failure of the circuit view” of QOS in Internet • Rise of Differential Services (DS) • A kinder gentler QOS for the Internet • Separation of “policy” and “forwarding” • DS Byte (codepoints), Per-Hop Behavior, Conditioners • Services: potentially many, e.g., traditional service • “Virtual Lease Line” Service • Today we will discuss a contribution to the next IETF meeting in Florida • A Framework for Differential Services • <draft-ietf-diffserv-framework-01.txt> • by Bernet et al.

3. The “S” Word • Scalability is is a big deal for Internet • Philosophy • pushes the complexity of supporting flows, etc., out of the core network into the edge devices which typically processes low volumes of traffic and lesser flows • offers services for aggregated traffic rather than on a flow basis as in Integrated Services • hence minimizing the state management problem

4. What is a Service in DS? • DS can support a broad spectrum of new services • that is the spin • A service is defined as • the overall treatment of a defined subset of a customer’s traffic with a DS-domain or on an end-to-end basis • PHB define • this treatment (e.g., Expedited and Assured Services) in conjunction with the marking traffic • are building blocks for services • Service is provided using PHB along with • traffic conditioners • provisioning strategies • pricing and billing models

5. Service Providers and Customers • Service Level Agreements • Service providers and customers negotiate agreements with respect to services to be provided at each customer/provider boundary called • “Service Level Agreements” or SLAs for short • Services are usually • for unidirectional traffic only • for traffic aggregates and not individual flows/ microflows

6. Traffic Conditioning Agreements (TCAs) • A subset of the SLA is associated with the traffic agreement • A traffic conditioning agreement details the service parameters for each service level and could include • detailed performance parameters • throughput, latency, etc. • traffic profiles • token buckets • excess traffic policy • marking services • shaping services • Comment: Indeed rather complex

7. Service Level Agreements ++ • May specify more general service characteristics • availability/reliability • routing constraints • authentication services • mechanisms for monitoring and auditing the service • pricing and billing

8. Services: quantitative and qualitative QOS • Both quantitative and qualitative may be offered • Likely that quantitative is first • Old ToS Byte in IP Header had a qualitative meaning • DS qualitative could mean • service level X will be delivered with low latency and • service level Y with low loss • DS quantitative could mean • 90% of in profile traffic delivered at service level Z will experience no more than 50 msec latency • But how to do this? • SLAs: profiling, marking, policing and traffic PHB • End-to-end services • need to negotiate SLAs across multiple domains • ingress and egress points

9. Static and Dynamic SLAs • Static SLAs agreed in advance between the customer and provider and don’t change too much • Dynamic SLAs • may change frequently • may respond to variations in offered traffic load relative to thresholds • dynamic pricing offered by the provider as load changes • Question: how is the signaling done? • Needs a dynamic control system, • e.g., some signaling and the bandwidth broker and agent technologies

10. Dynamic SLAs, Customers and Apps. • Static SLAs rely on quasi-static provisioning and engineering techniques to support the SLA • Dynamic is a completely different “kettle of fish” • need dynamic resource provisioning and signaling infrastructure - looks like on-demand IS? • customers may have to adapt with dynamic SLAs and there has to be an incentive for them to want to do that • applications that run on the customer hosts/network need to be able to respond to these changes too • that is now big deal today since most ‘good’ apps have built in adaptive mechanism that allow them to operate under diverse conditions • note that the customer could change the SLA but not likely to accommodate new flows, more likely, aggregate conditions

11. Provisioning • Once and SLA is agreed upon the service provider will configure the traffic conditioning components at the customer/provider boundary

12. Traffic Conditioning Components • Provider identifies the customer and service level of traffic submitted to the network • It configures traffic conditioning components • meters, markers, shapers and droppers • the combination and interaction of the traffic conditioning components is selected on a packet-by-packet basis by DS codepoint • the configuration for the components at each codepoint are determined by the policies and profiles applied

13. Meters, markers, shapers, droppers • Meters • measure submitted traffic for components to a profile, providing controlled input for other components which implement policing • Shapers • police by delaying submitted traffic such that it does not exceed the traffic rate specified in a profile • Droppers • police by dropping traffic that is submitted at a rate exceeding that specified in a profile • Markers • police by re-marking traffic to a different PHB, e.g., to demote out-of-profile traffic

14. Classifiers • Classifiers • separate submitted traffic into different classes • Keys on • DS, multiple fields in the header or packet payload • Multiple field may be used to key on a microflow at a boundaries, for example, providing support for marking and shaping before the data enters a DS domain • Typically traffic will arrive at the boundary of a DS domain pre-marked and pre-shaped; • this is not always the case so the provider may need to take care of this for non-DS customers that have no knowledge of these internal mechanisms • Also, even if the traffic is pre-conditioned the provider may wish to police it at the ingress regardless - to meet its own interests

15. Providers Ingress Functions • A simplified TCA: simple service realization • DS mark - profile - disposition of non conforming traffic • This indicates that the provider commits to carry traffic marked with the ‘DS mark’ at the corresponding service level provided that it conforms to the ‘Profile’ • Traffic that does not conform to the “Profile” is subject to policing action such as • re-marking to a lower level, delaying in a shaper or dropping • Classifier demuxs on DS mark and each class metered for conformance to its profile • Customer is responsible for marking and shaping packets • Provider may be required to support these functions too: marking and shaping flows, etc., on behalf of the customer at the ingress to the provider but there are limitations here

16. Edge Solution • For EN example: A multi-field classifier sorts packets at the edge devices and marks the DS field in the IP header appropriately • For ISP example: Option 1) mark all packets as they enter at the customer interface. Option 2) mark packets after classify on a MAC level destination test mark 7 Multifield classifier mark 5 Packet forwarding mark 1 Mark 0 Edge device for EN example

17. Customer’s Egress Functions • Issue • the provider may not have the capability to pre-mark and shape 1000,000 of short lived flows at its ingress. • It could of course to this on a subnet or gross level • So the customer may need to support these functions at its egress • It may want to ‘shape traffic per service level’ as a min requirement into the ISP as below

18. Solution : class selector compliant PHB Group • For EN example: Assign DS field vale “7” (111000) for network control, “5” for internal web-surfing, “1” for file transfer, “0” for external web-surfing • For ISP example: Assign DS field vale “7” (111000) for network control, “5” for top customer, “1” for mid level customer, “0” for budget service Class 7 DS field classifier Class 5 Packet scheduler Class 1 default Output interface of all network nodes

19. Providers’ Egress Functions • Likely to have a SLA with peer DS domain which might be another ISP or end-user domain • Therefore the ISP needs to • police, shape and re-mark at the egress point • Special treatment toward a customer site might call for policing mircoflow traffic into the customers site

20. End-to-end Service (An assignment for you!) • The proposes that an end-to-end service can be constructed by the concatenation of domain services and their associated customer-provider SLAs for each of the domains which the service has to cross • Assignment • due December 1st, 1998. • Outline a DS architecture for an end-to-end service • Only two pages and one diagram please • Mail HTML file to mk@comet.columbia.edu

21. “Virtual Lease Line” Rules • Traffic conditioners needed at egress boundary • shape the packets to rate B burst • uses a “holding queue” in front of shaper for same drop characteristics as a dedicated line • marks the packets with code for EF • ISP • police the marked packers across the boundary B • mix these marked packets with others throughout its domain but maintain EF PHB at each hop • have agreement across its borders for appropriate amount of marked traffic shape to those agreements

22. Example from [Nichols,98]

23. Schedule • Class schedule • December 1st at 12 noon • December 10th (Thursday) at 4 PM • Detailed Design run through • December 8th (Tuesday) at 4 PM • Mesut will mail list and set up times • Lab open please use it