EECS 122: Introduction to Computer Networks Resource Management and QoS

1. EECS 122: Introduction to Computer Networks Resource Management and QoS Computer Science Division Department of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA 94720-1776

2. Quality of Service (QoS) • The Internet’s most contentious subject • Inside vs. Outside the Network (see P&D, pp. 519-520) • The Internet’s most embarrassing failure • Many papers and proposals, but almost nothing accomplished

3. Today’s Lecture • What “could be”, not what is • Today’s Internet does not have, nor soon will have, a reasonable QoS solution • Focus on what one could accomplish with simple (and not-so-simple) mechanisms • Understand the basic concepts • Current deployed mechanisms not discussed • Ugly hodge-podge of hacks

4. What’s the Problem? • Internet gives all flows the same “best effort” service • No promises about when or whether packets will be delivered • Not all traffic is created equal • Different “owners”, different application requirements • Some applications require service “assurances” • How can we give traffic different “quality of service”? • Thus begins the problem of QoS

5. Three Basic Problems • Control how a link is shared: • Link sharing (discussed by Ion last lecture) • Give some traffic preferential service • Differentiated service • Give some flows “assured” service • Integrated service (and perhaps differentiated service)

6. A Different Taxonomy • Giving better service can differ along three dimensions: • Relative versus absolute • Dropping versus delay • Flows versus aggregates • Each choice requires different mechanisms • Intra-Router: Scheduling and dropping decisions • Inter-Router: Signaling protocols

7. Three Basic Questions • How does a router service this packet? • Scheduling (various forms of priority and RR) • Dropping (fancy versions of RED) • How does the router know what to do with this packet? • Bits in packet header or explicit signaling • How do we control the level of traffic? • Service level agreements (SLAs) or admission control

8. Back to Three Basic Problems • Link sharing (last lecture): not covered today • Differentiated Services • Integrated Services • Nice web site describing DiffServ and IntServ in succinct language: http://www.rhyshaden.com/qos.htm

9. Differentiated Services • 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

10. Traffic Limitations • Can’t give all traffic better service! • Lake Wobegone: Every flow gets better than average 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

11. 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

12. DiffServ Code PointPacket 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)

13. “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 • Unlikely • More likely, a way to assure relatively low delay

14. 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

15. “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 • Implemented using variations of RED • Different drop probabilities for different classes

16. 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

17. Advantages of DiffServ • Very simple to implement • Can be applied at different granularities • Flows • Institutions • Traffic types • Marking can be done at edges or by hosts • Allows easy peering (bilateral SLAs)

18. DiffServ Peering • 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-2 DS-1 Egress Ingress Egress Ingress Edge router Core router

19. Disadvantages of DiffServ • Service is still “best effort”, just a “better” class of best effort • Except for EF, which has terrible efficiency • All traffic accepted (within SLAs) • Some applications need better than this • Certainly some apps need better service than today’s Internet delivers • But perhaps if DiffServ were widely deployed premium traffic would get great service (recall example)

20. Integrated Services • Attempt to integrate service for “real-time” applications into the Internet • Known as IntServ • Total, massive, and humiliating failure • 1000s of papers • IETF standards • and STILL no deployment ...

21. Key Differences • All assurances on a per-flow basis • Traffic can be turned away • Note: • Co-exists with best-effort service • Similar mechanisms proposed for ATM but • QoS central in ATM, best-effort an afterthought • Best-effort central in Internet, QoS an afterthought

22. Example: Video Simplify by assuming that Camera sends at a fixed rate Nick McKeown

23. Circuit-Switched Networks • Each packet experiences exactly the same delay • Packet data is displayed as soon as it arrives • Signal at receiving end is faithful representation

24. Internet • Individual packets experience different delays • Can’t treat network as a “wire” • Application must adapt to network service

25. Router Effect on Delay Prob Delay variation or Jitter 99% Delay/latency e.g. 30ms Min

26. Router Effects on Traffic Router 1 Cumulative Bits bits in the network Source delay Time

27. Network Effects on Traffic Router 1 Router 2 Cumulative Bits bits in the network Source delay Delays do not build up independently in each router Svc function at router 1 is arrival function at router 2 Time

28. Network Effects on Traffic Router 1 Router n Cumulative Bits bits in the network Source delay Svc function at router 1 is arrival function at router 2 Time

29. Network Effects on Traffic Router n Cumulative Bits bits in the network Source delay Time

30. Network Effect on Delay Prob Delay variation or Jitter 99% Delay/latency e.g. 200ms Min Nick McKeown

31. Choices • Play back data upon arrival • Distorted signal • Buffer data for a while (playback buffer) • Extra delay, less distortion • Tradeoff depends on application (and use) • Noninteractive: absorb delay, eliminate all distortion • Interactive: absorb only a little delay, eliminate some distortion

32. Playback Buffer Play back data a fixed time interval after it was sent Source Destination Cumulative Bits Playout buffer delay Playout delay Time Playback Delay

33. Playback Point Playback point Nick McKeown

34. Adaptation • Can move playback point as delays vary • Moving playback point: • Increases distortion • But allows lower delays

35. Application Taxonomy (Oversimplified and Fanciful) • Elastic versus “real-time” • Traditional data apps are elastic • Streaming media are real-time • RT intolerant versus RT tolerant • Intolerant applications need all data • Tolerant nonadaptive versus tolerant adaptive • Not clear why any tolerant app couldn’t adapt • Rate-adaptive versus delay-adaptive (or both)

36. Key Points • Some apps don’t need to know maximal delay, just need it to be controlled • Tolerant, delay-adaptive applications will move playback point to reduce delay • Can absorb occasional outliers • Some apps need to know maximal delay • Can’t tolerate loss or distortion • Need to fix playback point and so need a priori knowledge of delay bound • Bound is typically much worse than actual delays

37. Two Service Classes • Controlled Load • Keep delays under control, but no bound • Guaranteed Service • Explicit delay bound

38. Process • Flow requests service from network • Service request specification (RSpec) • Controlled load: nothing • Guaranteed: service rate (can calculate delay) • Traffic specification (TSpec) (next slide) • Routers decide if they can support request • Admission control • If so, traffic is classified and scheduled at routers based on per-flow information

39. Problem • How do you describe bursty traffic? • Network needs some description of traffic • But video source is bursty (due to coding) • Can’t predict in advance the exact behavior • Describe “envelope” of traffic: rate and burstiness • Bits sent between times s and t: A(s,t) ≤ s + r(t-s) r : average rate s : burstiness

40. TSpec: The Token Bucket Tokens at rate,r r : average rate s : burstiness Token bucket size,s Packets Packets One byte (or packet) per token Packet buffer Bits sent between times s and t: A(s,t) ≤ s + r(t-s) Nick McKeown

41. Required Elements • Reservation Protocol • How service request gets from host to network • Admission control algorithm • How network decides if it can accept flow • Packet scheduling algorithms (covered last lecture) • So routers can deliver service

42. Control Plane vs. Data Plane • Control plane: • How information gets to routers • Data plane: • What routers do with that information to data packets Control Data

43. Control Plane: Resource Reservation Receiver Sender

44. Control Plane: Resource Reservation Sender sends Tspec Receiver Sender

45. Control Plane: Resource Reservation Path established Receiver Sender

46. Control Plane: Resource Reservation Receiver Sender The receiver signals reservation request

47. Control Plane: Admission Control Receiver Per-flow state Sender

48. Control Plane: Admission Control Receiver Per-flow state on all routers in path Sender

49. Data Plane Receiver Sender Per-flow classification on each router

50. Data Plane Receiver Sender Per-flow classification on each router