Quality of Service

1. Quality of Service Outline Realtime Applications Integrated Services Differentiated Services CS 332

2. Application Classes • Elastic: applications that can work fine without guarantees of timely delivery of data • Telnet, FTP, email, Web browser, etc. • Real-time: sensitive to timeliness of data • Late data is completely worthless • Voice and video applications, industrial control, etc. • Hard real-time: data late => disaster (possible loss of life) • Soft real-time: data late => headache We consider only soft real-time here CS 332

3. Sampler , Microphone Buffer , A D D A converter Speaker Realtime Applications • Require “deliver on time” assurances • must come from inside the network • Example application (audio) • sample voice once every 125us • each sample has a playback time • packets experience variable delay in network • add constant offset to playback time: playback point • trouble only if playback buffer drained CS 332

4. Playback Buffer Packet arrival Packet generation Playback Sequence number Buffer Network delay T ime CS 332

5. Delay Variability 90% 97% 98% 99% 3 2 Packets (%) 1 50 100 150 200 Delay (milliseconds) CS 332

6. Taxonomy of RT Apps • Tolerance of data loss (loss = late or lost packets) • Tolerant: can tolerate occasional loss (e.g. can interpolate to overcome loss of a single packet in audio stream with little effect) • Intolerant: even single lost packet is problematic (e.g. industrial control “shut-down” packet) • Note real-time can be more tolerant than non-real-time (consider FTP) CS 332

7. Taxonomy of RT Apps • Adaptability • Ex. Can (and do) adjust playback point in audio stream slightly while executing • Delay-adaptive applications: can adjust playback point • Rate-adaptive applications: can trade off bit rate versus quality (e.g. video apps can use coding algorithms with parameters that can be set for differing levels of quality) • Internet service model good for elastics, but obviously not good for the rest of the crowd CS 332

8. Taxonomy Applications Real time Elastic Asynchronous Interactive Interactive T olerant Intolerant bulk Adaptive Nonadaptive Rate-adaptive Nonadaptive Delay- Rate- adaptive adaptive CS 332

9. Approaches • Fine-grained: provide QoS to individual apps or flows • Integrated Services: developed by IETF and typically associated with the Resource Reservation Protocol (RSVP) • Coarse-grained: provide QoS to larges classes of data or aggregated traffic • Differentiated Services (currently undergoing standardization) CS 332

10. RSVP Service Classes • Guaranteed: network guarantees maximum delay that any packet will experience • For intolerant apps • Controlled Load: emulates a lightly loaded network, even if network is heavily loaded • For tolerant, adaptive apps • Use queuing (i.e. WFQ) to isolate controlled load traffic • Ex. Audio teleconferencing app vat • Adjusts playback point according to network delay • Can tolerate up to 10% packet loss CS 332

11. Implementation Issues • Need to tell network what QoS we need (give it a flowspec) • Network needs to decide if it can provide requested service (admission control) • Need way for network and user to communicate the above and other service info (resource reservation, a.k.a. signalling) • Network routers need way to meet service requirement (packet scheduling) CS 332

12. Flowspec • RSpec: describes service requested from network (relatively easy) • controlled-load: none • guaranteed: delay target or related info • TSpec: describes flow’s traffic characteristics (not so easy) • Need to give network enough info to make intelligent admission control decisions • Average bandwidth fails to account for burstiness (think of 10 flows with average rate of 1 MBps each being multiplexed onto 10MBps link) CS 332

13. Example TSpec: Token Bucket • Average bandwidth + burstiness: token bucket filter • Token rate r • Bucket size B • Must have n tokens to send n bytes • Accumulate tokens at rate of r per second (start with 0) • Can accumulate no more than B tokens • Can send any “bytes” in bucket as fast as you can/wish • Ex. Flow A: r = 1 MBps, B = 1 Flow B: r = 1 MBps, B = 1 MB (note could describe A with same TSpec) Note: be explicit, save resources CS 332

14. Admission Control • Look at RSpec and TSpec and decide whether to admit new flow based on available resources and other commitments • Per-Router mechanism • Very dependent on type of requested service and queuing disciplines in routers • Not same as policing (checking that individual flows are adhering to their advertised RSpec) CS 332

15. RSVP • Significantly different than typical signalling protocols for connection-oriented networks • Key assumption: do not detract from robustness of connectionless network • Lack of router state in connectionless allows for end-to-end connectivity even during crash and reboot cycles • RSVP uses soft state: does not need to be explicitly deleted when no longer needed (instead refresh periodically) CS 332

16. RSVP (cont.) • Goal: support multicast as effectively as unicast(?!) • Receiver-oriented protocol • Because multicast typically has lots more receivers than senders (senders shouldn’t need to keep track of all this) • Because receivers have different requirements and may wish to receive from different sets of senders • Nice properties: • Easy to change resource allocations provided to receiver • Periodic refresh handles host crashes, down links, and the like CS 332

17. RSVP (yet again) • Sender transmits PATH message containing TSpec, routers along path record reverse path from receiver to sender • Receiver sends RECV message back up tree with Tspec and Rspec. • Each router along path performs admission control. If yes, pass RECV toward root of tree, if no, send an error message to receiver • Source transmits PATH messages every 30 seconds • Destination transmits RESV message every 30 seconds • Merge requirements in case of multicast • Can specify number of speakers CS 332

18. RSVP Example CS 332

19. Packet Processing • classification: associate each packet with the appropriate reservation • Examine source address, dest address, protocol number, source port and dest port (or use single FlowLabel field in IPv6) • Use mapping from flow-specific info to service class identifier • Guaranteed: mapping may be one-to-one • Controlled load: mapping may be many-to-one • scheduling: manage queues so each packet receives the requested service (not simple) • Guaranteed: probably some form of WFQ • Controlled load: maybe aggregate flows into single stream and use a form of WFQ • Difficulty: many services provided concurrently, each requiring its own scheduling algorithm CS 332

20. A Big Problem… • Consider the following: an OC-48 (2.5 Gbps) link representing several multiplexed 64 Kbps audio streams. Number of flows is thus: (2.5  109)/(64  103) = 39,000 • Each flow has associated state which needs to be periodically refreshed • Each flow needs to be policed, classified, queued, etc • So clearly the problem is scalability (it’s BAD!) CS 332

21. Differentiated Services • Solves scalability problems by allocating resources to small number of classes of traffic • Premium • Best-effort • Once packets marked, how are they handled? • IETF standardizing set of per-hop behaviors (PHBs) • Redefined TOS byte from IP header: six bits allocated for Differentiated Services code points (DSCP), which determines which PHB gets used. CS 332

22. Example PHBs • Expedited Forwarding (EF) • Packets marked EF forwarded with minimal delay and loss • Potential implementation strategies: • Give EF strict priority over other packets • Perform WFQ with EF packets, with weight set high enough to guarantee necessary EF packet bandwidth (better than above since helps prevent starvation for non-EF packets, including things like routing update packets) CS 332

23. Example PHBs (cont.) • Assured forwarding (AF) • Based on RED with In and Out (RIO) or Weighted RED • Two classes of packets, “In” (green curve) and “Out” Used in conjunction with “profile meter” CS 332