Integrated and Differentiated Services

1. Integrated and Differentiated Services Christos Papadopoulos CS551 – Fall 2002 (http://netweb.usc.edu/cs551/)

2. Motivation • Some applications require minimum level of network performance • Some less elastic applications are not able to adapt to changes in bandwidth and delay • bandwidth below which video and audio are not intelligible • internet telephones, teleconferencing with high delay (200 - 300ms) impair human interaction

3. The Problem

4. A Class of Real-time Applications • Playback applications • set a playback point in the future • buffer packets until playback point • Features that you can leverage • early packet arrival ok • performance improves with lower delay • need absolute or statistical bound on delay • tolerate some loss

5. Rigid V.S. Adaptive Applications • Two classes of playback applications • Rigid/adaptive • Tolerant/intolerant • The distinction here is whether the application would tolerate interruptions • Rigid applications • Set fixed playback point (a priori bound) • Adaptive applications • Adapt playback point (de facto bound) • A priori bound > de facto bound

6. Adaptive Applications • Gamble that network conditions will be the same now as in the past • Are prepared to deal with errors in their estimate • Will in general have an earlier playback point than rigid applications • Experience has shown that they can be built (e.g., vat, various adaptive video apps)

7. Real-Time Applications Loss, delay tolerant Intolerant adaptive Non-adaptive Rate adaptive Non-adaptive Delay adaptive Rate adaptive Real-time Applications

8. Architectural Components • Commitments made by network • type of service the network provides • Service interface • characterization of source traffic • characterization of QoS network will deliver • Packet scheduling • algorithms, information in headers • Admission control • policing

9. Types of Network Service Commitments • Guaranteed service • For intolerant and rigid applications • Predicted service • For tolerant and adaptive applications • Applications gamble, why not the network? • Two components: • If conditions do not change, commit to current service • If conditions change, take steps to deliver consistent performance (help apps set playback point by minimizing post facto delay bounds)

10. Service Interface: Flowspecs • Tspec: describes the flow’s traffic characteristics • Rspec: describes the service requested from the network

11. Token Bucket Filter • Described by 2 parameters: • token rate r: rate of tokens placed in the bucket • bucket depth B: capacity of the bucket • Operation: • tokens are placed in bucket at rate r • if bucket fills, tokens are discarded • sending a packet of size P uses P tokens • if bucket has P tokens, packet sent at max rate, else must wait for tokens to accumulate

12. Token Bucket Operation tokens tokens tokens overflow Packet Packet Not enough tokens - wait for tokens to accumulate Enough tokens packet goes through, tokens removed

13. Token Bucket Characteristics • In the long run, rate is limited to r • In the short run, a burst of size B can be sent • Amount of traffic entering at interval T is bounded by: • traffic = B + r*T • Information useful to admission algorithm

14. Token Bucket Specs Flow A: r = 1 MBps, B=1 byte BW Flow B Flow B: r = 1 MBps, B=1MB 2 1 Flow A 1 2 3 Time

15. Possible Token Bucket Uses • Shaping, policing, marking • delay pkts from entering net (shaping) • drop pkts that arrive without tokens (policing) • let all pkts pass through, mark ones without tokens • network drops pkts without tokens in time of congestion

16. Guarantee Proven by Parekh • Suppose a flow • gets a rate r at every router in network • and all routers in network do WFQ • … and the corresponding token bucket burst size is b • Then, in any arbitrary topology • Cumulative queuing delay Di suffered by flow i has upper bound b/r • even if the switch is shared with unshaped flows • This result holds for a fluid flow approximation • Additional terms to the delay bound with a packet approximation • Intuition: • Imagine flow i shaped with token bucket, • … then all delay is incurred at entrance to network

17. Scheduling Guaranteed Traffic • Use token bucket filter to characterize traffic • Use WFQ at the routers • Parekh’s bound for worst case delay • So why not only have guaranteed and best effort • Delays can be high unless one reserves a rate r which is higher than the average rate • Network can then be significantly underutilized

18. Predicted Service • WFQ not suitable • Provides isolation, but the delay is not shared • … and can self-impose jitter in post facto delay • FIFO with multiple priority levels might work • But jitter can increase in a multi-hop case • So, use FIFO+ • At each hop: measure average delay for class at that router • For each packet: compute difference of average delay and delay of that packet in queue • Add/subtract difference in packet header

19. Predicted Service: FIFO+ Simulation • Simulation shows: • slight increase in delay and jitter for short paths • slight decrease in mean delay • significant decrease in jitter • However, more complex queue management

20. Unified Scheduling • Assume 3 types of traffic: guaranteed, predictive, best-effort • Scheduling: use WFQ in routers • each guaranteed flow gets its own queue • other traffic aggregates in separate queue • predictive traffic classes: strict priority with FIFO+. Several classes separated by order of magnitude delay (sum of delays at each hop) • best effort traffic gets lowest priority

21. Service Interface • Guaranteed traffic • specifies rate (but not bucket size! Why?) • if delay not good, ask for higher rate • Predicted traffic • specifies (r, b) • selects delay, loss, network assigns priority • policing at edges to drop or tag packets

22. But… • Do we really need Integrated Services? • Do we need to change the network service model? • Or, do we just let applications adapt, and engineer the network for enough bandwidth? • How do we even study this question?

23. Fundamental Design Issues for the Internet Shenker95a

24. Key Ideas • Do we need to extend the Internet service model (currently best effort)? • Reservations, admission control, etc, or • Overprovision and keep best effort • How do we even study this question? • Simple model, very high level view • Asks fundamental questions • Helps guide the thinking for a very hard question

25. Model: Utility and Efficacy • Does the network make users happy? • Define U(j) be the utility delivered to the jth user • U(j) maps the network’s performance to the user’s level of happiness • For example, higher bandwidth delivered to a video application (up to a point) makes the user happier • Similarly, lower delay delivered to application makes user happier • Goal of network is to maximize • … the sum of all U(j)s (the efficacy, denoted by V)

26. More Bandwidth or New Service Model? • In a best-effort network, can increase bandwidth to increase efficacy • Or, for the same bandwidth, introduce new services matched to application needs • … and increase efficacy that way • Key question: what’s the relative cost of adding bandwidth and adding new services • Shenker: always better to add new services • Makes better use of available bandwidth • But cost of adding new services hard to estimate

27. Other Considerations • Do separate networks for different applications provide higher efficacy? • No. A single network can always use leftover bandwidth to increase efficacy • Note: increasing efficacy does not mean increasing everyone’s utility • Service models must map application requirements • Otherwise, none of these arguments holds

28. Implicit V.S. Explicit Service Request • Should applications explicitly request service, or should the network determine service to deliver? • Implicit doable if number of services is small and well known and stable (e.g., port number) • Need to embed application knowledge inside the network (BAD!) • Explicit supports larger variety of services but incentives needed so all do not request highest service • Applications must know what they want! • Pricing, accounting and billing: these are hard • Stable service model needed so apps know what to request • Major coordination effort (imagine changing IP or Ethernet..)

29. Admission Control? • Overload: a network is overloaded if by removing a flow would increase V even though there are fewer flows • If V(n) does not continue to increase as n goes to infinity, then we either need admission control or over-provisioning • Best Effort never overloads (or does it?)

30. Utility Curve Shapes Elastic Hard real-time U U BW BW Delay-adaptive If convex near origin, then need admission control U BW

31. Over-provisioning • Works for “normal users” because need to overprovision by a small amount • Over-provisioning for “leading edge” users is hard because these consume several orders of magnitude more than normal users • Internet will be provisioned to rarely block normal users, but will block leading edge users frequently

32. State of Integrated Services • Lots of work in the area • We understand many of the problems • But no commercial interest in the technology • Too complex? • Can we build these schedulers in hardware? • Need per-flow state for scheduling • Can we do something simpler?

33. Differentiated Services (DiffServ)

34. Key Ideas • Traffic classes instead of flows • Forwarding behaviors instead of end-to-end service guarantees • Tune applications to network services rather than network services to applications • Discrete v.s. continuous space • No resource reservation • Somewhere between Best Effort and IntServ

35. Service Differentiation • Analogy: • airline service, first class, coach, various restrictions on coach as a function of payment • Best-effort expected to make up bulk of traffic, but revenue from first class important to economic base (will pay for more plentiful bandwidth overall) • Not motivated by real-time but by economics and assurances

36. Types of Service • Premium service: (type P) • admitted based on peak rate • conservative, virtual wire services • unused premium goes to best effort (subsidy!) • Assured service: (type A) • based on expected capacity usage profiles • traffic unlikely to be dropped if user maintains profile. Out-of-profile traffic marked

37. Differences With Integrated Services • No need for reservations: just mark packets • Packet marking done at administrative boundaries before injecting packets into network • Significant savings in signaling, much simpler overall

38. Service V.S. Forwarding Treatment • Service: end-to-end • Forwarding treatment: hop-by-hop (in each router) • Reasoning: various forwarding treatments can be used to construct same e2e service • Free to implement treatments locally in various ways (buffer management and scheduling) • Example: no-loss service implemented with priority queue (but needs admission control)

39. Service Level Agreements • Mostly static or long-lived (but see later) Specification: • Traffic profile (e.g., token bucket per class) • Performance metrics (tput, delay, drop priority) • Actions for non-conformant packets • Additional marking/shaping

40. Premium Service • User sends within profile, network commits to delivery with requested profile • Simple forwarding: classify packet in one of two queues, use priority • Shaping at trust boundaries only, using token bucket • Signaling, admission control may get more elaborate, but still not end-to-end

41. Premium Traffic Flow Company A Packets in premium flows have bit set Premium packet flow restricted to R bytes/sec internal router ISP host border router first hop router border router Unmarked packet flow

42. A Two-bit Differentiated Services Architecture for the Internet Nichols99a

43. Premium V.S. Assured Forwarding Behaviors • Premium packets receive virtual circuit type of treatment • Appropriate for intolerant and rigid applications • Assured packets receive “better than best effort” type of treatment • Appropriate for adaptive applications

44. 2-bit Differentiated Service • Precedence field encodes P & A type packets • P packets are BW limited, shaped and queued at higher priority than ordinary best effort • A packets treated preferentially wrt dropping probability in the normal queue • Leaf and border routers have input and output tasks - other routers just output

45. Leaf Router Input Functionality Marker 1 Flow 1 Marker N Flow N Forwarding engine Clear A & P bits Packet classifier Arriving packet Best effort Markers: service class, rate, permissible burst size

46. Marker Function in Routers • Leaf routers have traffic profiles - they classify packets based on packet header • If no profile present, pass as best effort • If profile is for A: • mark in-profile packets with A, forward others unmarked • If profile is for P: • delay out-of -profile packets to shape into profile

47. No token token Packet output Packet input Test if token Set A bit Markers to Implement Two Different Services Drop on overflow Packet input Packet output Wait for token Set P bit

48. Output Forwarding • 2 queues: P packets on higher priority queue • Lower priority queue implements RED “In or Out” scheme (RIO) • At border routers profile meters test marked flows: • drop P packets out of profile • unmark A packets

49. Router Output Interface for Two-bit Architecture yes P-bit set? High-priority Q Packets out no If A-bit set incr A_cnt Low-priority Q If A-bit set decr A_cnt RIO queue management

50. Red With In or Out (RIO) • For Assured Services • Similar to RED, but with two separate probability curves • Has two classes, “In” and “Out” (of profile) • “Out” class has lower Minthresh, so packets are dropped from this class first • As avg queue length increases, “in” packets are dropped