Berkeley-Helsinki Summer Course Lecture #10: Service Level Agreements and Clearinghouses

1. Berkeley-Helsinki Summer CourseLecture #10: Service Level Agreements and Clearinghouses Randy H. Katz Computer Science Division Electrical Engineering and Computer Science Department University of California Berkeley, CA 94720-1776

2. Outline • Applications and Performance • Service Level Agreements • Traffic Engineering to Deliver SLAs • Bandwidth Brokering • Clearing House

3. Outline • Applications and Performance • Service Level Agreements • Traffic Engineering to Deliver SLAs • Bandwidth Brokering • Clearing House

4. Different Applications and Network Requirements High Streaming Video Video Conferencing E-mail with Attachments Voice Bandwidth Requirements Internet/ intranet E-commerce ERP Text e-mail TerminalMode Transactions Low Low High Latency Sensitivity

5. Quality of Service • Application-level QoS • How well user expectations are qualitatively satisfied • Clear voice (mean opinion scoring), jitter-free video, etc. • Implemented at application-level: end-to-end protocols (RTP/RTCP), application-specific representations and encodings (FEC, interleaving) • Network-level QoS • Easier to quantify, measure, and control • Metrics include available b/w, packet loss rates, etc. • Elements of a Network QoS Architecture • QoS Specification (CoS—high vs. best, guarantees) • Resource management and admission control • Service verification and traffic policing • Packet forwarding mechanisms (filters, shapers, schedulers) • QoS routing

6. Heterogeneous Traffic Behavior and QoS Requirements Applications Electronic Mail (SMTP)File Transfer (FTP)Remote Terminal (Telnet) HTML Web Browsing Client-ServerE-Commerce IP-based Voice (VoIP)Real Audio Streaming Video Traffic Behavior Small, batch file transfers Series of small, bursty file xfer Many small 2-wayxacts Constant or vari-able bit rate Variable bit rate QoS Requirements Very tolerant of delayB/w requirement: lowBest effort Tolerant of moderate delayB/w requirement: variesBest effort Sensitive to loss/delayB/w requirement: low-modMust be reliable Very sensitive to delay/jitterB/w requirement: lowRequires predictable delay/loss Very sensitive to delay/jitterB/w requirement: High, variableRequires predictable delay/loss Chen-nee Chuah

7. TerminalModeTransactions Voice over IP VideoConferencing StreamingVideo Technical Strategies for Achieving Better QoS Application Solution Cache Internet/Intranet Queue E-mail Packet Shaping Largely Unsolved

8. Outline • Applications and Performance • Service Level Agreements • Traffic Engineering to Deliver SLAs • Bandwidth Brokering • Clearing House

9. What is a Virtual Private Network? • Alternative to a private network; uses the open, distributed infrastructure of the Internet to transmit data between corporate sites • Requires support for: • opaque packet transport • data security • Quality of Service Guarantees and/or SLAs • Provided by a single ISP; methods to span multiple ISPs not well developed

10. What is a Service Level Agreement? • Migration from managing corporate WAN to out-sourcing connectivity & transport to 3rd-party carrier • Informal contract between carrier and customer defining terms of carrier’s responsibility and type and extent of remuneration if those are not meet • Worst case/average r/t packet latencies (e.g., 100-300 ms) • Worst case/average packet loss rates • Worst case/average bandwidth • Expected up times between VPN end points (e.g., 99.5%/month) • Responsiveness to service complaints and outages • Access availability more important than b/w guarantees • Extensions: to services beyond transport and to services among multiple service providers

11. QoS in VPNs • Obtain differentiated & dependable QoS for flows belonging to a VPN • Performance service abstractions: • PIPE: provides performance guarantees for traffic between a specific origin and destination pair • HOSE: provides performance guarantees between an origin and a set of destinations, and between a node and a set of origins, i.e. it’s characterized by the “aggregate” traffic coming from or going into the VPN

12. Relationship BetweenVPN and SLA • SLA negotiated between customer & service provider • Traffic characteristics and QoS requirements • In practice, negotiated parameters are coarse grained • Support for different QoS classes within VPN • Resources are managed on a VPN-specific basis;SLAs negotiated for overall VPN rather than each specific QoS class • Schedule only at the edges • Mark packets and schedule within the core • Resources are managed on an individual QoS basis

13. SLA-VPN Summary • Different choices for the implementation of HOSES in VPNs • Integrated service framework (controlled load, guaranteed load) with signaling protocol like RSVP • Differentiated service framework (DS byte of IP header) • MPLS environment (LSP tree) • Security • IPSec is recommended with the VPN (secure tunnels) • Only limitation is scalability

14. Outline • Applications and Performance • Service Level Agreements • Traffic Engineering to Deliver SLAs • Bandwidth Brokering • Clearing House

15. Overview • Traffic Engineering • Definitions • Objectives • Various approaches • MPLS-based single-path traffic engineering • Framework for MPLS-based traffic engineering in a DiffServ network

16. Traffic EngineeringDefinitions: Traffic Trunk • Traffic Trunks • Behavior aggregate • Stream of packets equivalent from a forwarding point of view • Attributes for traffic engineering • B/w requirements and traffic characteristics • QoS requirements • Routing constraints • Survivability requirements 10 Mb/s, delay<150ms 0 1 2 3 4 6 5

17. Traffic Engineering Definitions:Survivability • Survivability (resilience): achieving a situation in which capacity is available in some or all failure conditions to restore (part of) the affected traffic • Protection type: 1:1 • Protection resource allocation: • Dedicated • Shared • Restoration mechanism: • Revertive (primary path can be used) • Non-revertive (service rolls over when path fails)

18. Traffic Engineering Definitions: Preemption, Release, Oversubscription • Preemption • In failure state, capacity made available by unaffected trunks to reroute high-priority affected traffic • Release • In failure state, capacity allocated to affected trunks can be released • Oversubscription • Capacity allocated on a link is less than the combined demands of all trunks running over the link (statistical multiplexing)

19. Traffic EngineeringObjectives • Goal: efficiently map traffic onto an existing network in such a way as to optimize • Utilization of network resources: facilitate the operation of the network • Performance of the network: ensure that the network offers its customers the QoS they purchased • Requirements: • Adaptability to changes in the network configuration • Capability to evolve existing traffic engineering solutions into new ones with a limited amount of service disruption • Capability to adhere to administrator-defined policies

20. Traffic EngineeringResource-oriented Objectives • Link capacity is allocated • Utilization is defined as the relative amount of link capacity that has been allocated • Load balancing • Maximizing balance • Balance is defined as (1 - maximum link utilization) • Goal: avoiding congestion • Minimizing capacity usage • Capacity usage is defined as the sum of all allocated capacity

21. Traffic EngineeringTraffic-oriented Objectives • Trunks receive a share of the capacity • Share: the absolute amount of b/w guaranteed to a trunk in excess of its agreement with the operator • Maximizing fairness • Fairness: minimum share relative to a weight measuring the expected excess bandwidth • Goal: avoiding arbitrary discrimination of some of the customers • Throughput • Maximizing the sum of all guaranteed bandwidths • Goal: maximizing revenue

22. Traffic EngineeringVarious Approaches • Manual traffic engineering by a team of experts • OSPF with optimized weights • Equal Cost Multi Path (ECMP) • Optimized Multi-Path (OMP) • MPLS label switching with constraint-based routing • MPLS label switching with offline traffic engineering tool

23. MPLS-based Traffic EngineeringProblem Taxonomy TE (LP) Linear program Multi-Path TE (MPTE) Single-Path TE (SPTE) (MINLP) Mixed integer non-linear program (MILP) Mixed integer LP MPTE-RO MPTE-TO SPTE-TO SPTE-RO • Exact algorithm based on MILP reformulation • Path-fixing heuristics

24. MPLS-based Traffic EngineeringNetwork Description • List of nodes • List of links: • Working/protection/total capacity • Link color • Utilization • Failure state description • Single link failures • Single node or link failures

25. MPLS-based Traffic EngineeringTrunk Description • List of source-destination pairs: • Demand (pipe model) • Protection type: shared, dedicated, ... • Protection level: support of partial protection • Preemption level: support of partial preemption • (Weighted) share • List of available paths

26. 0 1 2 3 8 7 4 6 5 MPLS-based Traffic EngineeringRouting Description • Path are selected from a list of available paths • Path list construction: • No survivability: • k shortest paths • Survivability: • overlap definition • sorted k shortest paths • paths are added that minimize the overlap with the existing set 4 3 1 2

27. MPLS-based Single-Path TESurvivability • Single node and link failures only • Fast reroute: • unique protection path • no release • No backup capacity allocation on single-point of failure links • Choice between shared/dedicated protection

28. MPLS Support of DiffServ • DiffServ: Per-Hop Behaviors • Expedited Forwarding: absolute bandwidth, delay & delay jitter and packet loss guarantees • Assured Forwarding: relative bandwidth, delay & delay jitter and packet loss guarantees • Best Effort: connectivity guarantee • MPLS support: • L-LSP: label inferred, different label per BA • E-LSP: exp-inferred, different label per OA

29. DiffServ Requirements • Bandwidth differentiation • bandwidth & capacity allocation model • traffic classes • traffic types & capacity allocation • setting the excess bitrates • Delay and delay jitter differentiation • Loss differentiation

30. Traffic Engineering ModelB/W & Capacity Allocation Model bandwidth guarantee to trunk k guaranteed bandwidth Dk+ yk committed bitrate dk peak bitrate Dk 0 Dk+ Dk share yk excess bitrate Dk unconditional guarantee: no oversubscription conditional guarantee oversubscription factor sk partial conditional guarantee (fair allocation of remaining capacity, oversubscription) dedicated capacity dk allocated capacity dk+sk-1(Dk-dk+yk) 0 capacity allocation on link

31. Traffic Engineering ModelTraffic Classes

32. Traffic Engineering ModelTraffic Types & Capacity Allocation

33. Traffic Engineering ModelNatural Setting of Excess Bitrates access network ingress sk effective access rate diffserv domain weighted fair allocation of unallocated capacity trunk k egress tk

34. DiffServ Requirements • Bandwidth differentiation • Delay and delay jitter differentiation • Forwarding • Scheduling • EF delay • Non-EF delay • Loss differentiation

35. Traffic Engineering ModelForwarding buffer acceptance scheduling input output loss queueing

36. SP WTP WFQ WFQ Traffic Engineering ModelScheduling EF R(EF) AF1 AF2 AF3 R(AF) AF4 R(BE) BE

37. DiffServ RequirementsDelay Differentiation: EF Delay • Delay of a single EF-hop • Markov process, low signaling load • Delay of a series of EF-hops • asymmetric EF-load: lightly-heavily loaded links • Busy periods of EF-traffic • Conclusion • Delay upper bound expressed as upper bound on EF-load • Delay jitter < Dqueue

38. DiffServ RequirementsEF Delay Differentiation (1-P) quantiles of the queuing delay of EF packets 20 decreasing P queuing delay [ms] 0 0 50 100 EF load [%]

39. DiffServ RequirementsDelay Differentiation: Non-EF Delay • WFQ with service interruptions • fluid flow assumption • exponential distributions • Conclusion: • service differentiation possible • proportionality difficult to ensure in all cases low-priority traffic queues Service interrupt of low-priority traffic class 1 b1 R(1-Pint) R b2 WFQ Pint class 2 Tint b3 Busy periods of high-priority traffic class 3

40. DiffServ RequirementsNon-EF Delay Differentiation Average delay ratio class 1 load class 5 load

41. DiffServ RequirementsLoss Differentiation • Loss calculations are made based on • Buffer rejection prob of class c with drop precedence d

42. Verifying that SLAs are Satisfied • Carrier-based reports • Interpretation of report and its statistics • Gaps in statistics gathering • Process for gathering data • Optimization of the network • Capital investment to evolve the network • Recurring transmissions costs • Bandwidth growth caused by rogue users/apps • Ability to warn users before performance degradation becomes noticed • Active monitoring may be necessary

43. Outline • Applications and Performance • Service Level Agreements • Traffic Engineering to Deliver SLAs • Bandwidth Brokering • Clearing House

44. Internet2 Research Project • Quality of Service Backbone (QBone) • Experimental deployment of DiffServ capabilities into a WAN networking testbed to determine what works and doesn’t work • DiffServ tenets: • Aggregation into small # of DS behavior aggregates in core • Bilateral service level agreements (SLAs) between domains • Max flexibility in local resource management decisions • Bandwidth Broker (BB) Architecture for cooperatively allocating bandwidth among network flows • Premium vs. best effort service • Focus on inter-domain signaling, with separate schemes for DiffServ implemented in each participating domain

45. Internet2 Research Project • Bandwidth Broker Resource Managers • Based on IETF DiffServ • Service Level Specification/Negotiation left unaddressed • Only kind of service currently managed is QBone Premium Service (QPS) • Quantitative, absolute b/w assurance within a domain, intra-domain from edge to edge, or inter-domain • No loss due to congestion, no latency guarantees, worst-case jitter bounds (except for IP route changes) • Generalization to other kinds of services • When/where will service be provided? • How is desired level of service specified? • How is provided service described? Quantitative vs. qualitative

46. BB RSVP SLA Transit Domain 2 ER SLA BB BB ER ER Transit Domain 1 SLA ER BB BB ER ER Data Flow ER Data Flow Source Domain Sink Domain

47. Bandwidth Brokers • Brokers as “Oracles” • Receive resource allocation request (RAR) from • An element in the domain that the BB controls • A request from a peer (adjacent) bandwidth broker • Admission control: BB responds with confirmation or denial of service via a Resource Allocation Answer (RAA) • Input to BB: space-time coordinates of the service, kind of service (its parameters), characteristics of the input • SLAs in this context • Bilateral, concluded between peered domains • Guarantee traffic offered by (peer) customer domain, meeting certain conditions, carried by the service provider domain to one or more egress points with one or more particular service levels • May be hard or soft, carry tariffs, and certain monetary or legal consequences if not met

48. Bandwidth Brokers • SLS in this context • Contains technical details of the SLA • Asserts traffic of a given class, meeting specific policing conditions, entering the domain on a given link, will be treated according to a particular PHB(s)—per hop behaviors (e.g., expedited forwarding) • If traffic destination is not receiving domain, then pass it to another domain (on path toward destination according to routing tables) with similar (compatible and comparable) SLS specifying an equivalent (set of) PHB(s) • TCS: Traffic Conditioning Specification • Specifies classifier rules, corresponding traffic profiles & metering, marking, discarding, shaping rules applied to traffic aggregates selected by the classifier

49. Bandwidth Brokers • Reservations • Actually committed resources, but not necessarily used • Tracked by BB, shared with network management system • Actual resource use tracked by routers, possibly monitored by bandwidth broker

50. Bandwidth Brokers:Nodal Architecture