1. Spring 2002CS 3321 Quality of Service Outline Realtime Applications Integrated Services Differentiated Services

2. Spring 2002CS 3322 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

3. Spring 2002CS 3323 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 Microphone Speaker Sampler, A D converter Buffer, D A

4. Spring 2002CS 3324 Playback Buffer Sequence number Packet generation Network delay Buffer Playback Time Packet arrival

5. Spring 2002CS 3325 Delay Variability 1 2 3 Packets (%) 90%97%98%99% 15020010050 Delay (milliseconds)

6. Spring 2002CS 3326 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)

7. Spring 2002CS 3327 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

8. Spring 2002CS 3328 Taxonomy Applications Real time Tolerant AdaptiveNonadaptive Delay- adaptive Rate- adaptive Intolerant Rate-adaptiveNonadaptive Interactive bulk Asynchronous Elastic

9. Spring 2002CS 3329 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)

10. Spring 2002CS 33210 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

11. Spring 2002CS 33211 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)

12. Spring 2002CS 33212 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)

13. Spring 2002CS 33213 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

14. Spring 2002CS 33214 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)

15. Spring 2002CS 33215 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)

16. Spring 2002CS 33216 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

17. Spring 2002CS 33217 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

18. Spring 2002CS 33218 RSVP Example

19. Spring 2002CS 33219 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

20. Spring 2002CS 33220 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  10 9 )/(64  10 3 ) = 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!)

21. Spring 2002CS 33221 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.

22. Spring 2002CS 33222 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)

23. Spring 2002CS 33223 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”