CAS CS 835

1. CAS CS 835 QoS Networking Seminar

2. What to expect? • Discuss latest developments and research issues, current and possible future QoS/CoS technologies • Queue management, traffic monitoring/shaping, admission control, routing, … • Focus on Internet extensions and QoS-sensitive protocols/applications • Integrated Services and RSVP • Differentiated Services • Multi Protocol Label Switching • Traffic Engineering (or QoS Routing)

3. What to expect? • Proposal: pre-proposal, full proposal, presentation • Paper presentation • 2 quizzes • Active participation

4. What is QoS? • A broad definition: methods for differentiating traffic and services • To some, introducing an element of predictability and consistency into a highly variable best-effort network • To others, obtaining higher network throughput while maintaining consistent behavior • Or, offering resources to high-priority service classes at the expense of lower-priority classes (conservation law) • Or, matching network resources to application demands

5. What is Quality? Service? Why Integrated? • Quality encompasses data loss, induced delay or latency, consistency in delays (jitter), efficient use of network resources, … • Service means end-to-end communication between applications (e.g., audio, video, Web browsing), a protocol type (e.g., TCP, UDP), … • A single network is better --- unused capacity is available to others, one network to manage • Better to give each user/traffic what it wants • QoS mechanisms for unfairness: managing queuing behavior, shaping traffic, control admission, routing, … • Engineering the network is hard, and over-engineering it is expensive (especially for long-distance links)

6. Why the recent interest in QoS? • No longer enough for an ISP to keep traffic flowing, links up, routing stable --- offer QoS to be more competitive • QoS is becoming more cost-effective with improved implementation of differentiation tools (classification, queue-manipulation, …), more reliable tools for measuring delivered QoS • Hard to dimension the network as it is becoming increasingly hard (if not impossible) to predict traffic patterns (e.g., 80 local/20 remote rule no longer reliable, now mostly reversed 25/75) • If you throw more bandwidth, there will be more demand (a “vicious cycle”)

7. Applications of a QoS Network • Real-time: voice, video, emergency control, stock quotes ... • Non-real-time (or best-effort): telnet, ftp, … • Real-time: - hard with deterministic or guaranteed QoS: no loss, packet delay less than deadline, difference in delays of 2 packets less than jitter bound, … Note: reducing jitter reduces buffers needed to absorb delay variation at receiving host - soft with statistical or probabilistic QoS: no more than x% of packets lost or experience delay greater than deadline, … • Best-effort do not have such timing constraints

8. Why end-to-end control not enough? • Problem: with common FCFS schedulers at routers, delay and delay variance increase very rapidly with load • For an M/M/1 model: average delay = 1 / [ServiceRate - ArrivalRate] = 1 / [ServiceRate (1 - Load)] delay variance = 1 / [ (1 - Load)] • As load increases, buffer overflows and router starts dropping packets • Solution: TCP reduces load (slow start and congestion avoidance algorithm) • 2 TCP users on different hosts sharing the same bottleneck may get different share of the bandwidth (uncontrolled unfairness) ==> users should not trust network • Some users may not “play by the rules” and reduce their sending rates upon congestion, i.e. not TCP-friendly sources like a voice or video UDP-based application ==> network should not trust users

9. How to provide guarantees? • Some form of resource reservation within the network; hosts can’t “hide” delays • Challenge: do it asynchronously (i.e., as needed), don’t reserve peak rate for a voice connection/flow active 30% of the time • Want to support as many real-time flows as possible to increase revenue • Key question: Can the network admit a new flow at its requested QoS, without violating QoS of existing flows? • A flow has to specify its QoS (Rspec) and also its traffic pattern (Tspec)

10. Contract or SLA • Service Level Agreement between client (subscriber) and network (provider): the network keeps its promise as long as the flow conforms to the traffic specification • The network must monitor/police/shape incoming traffic • The shape is important: E.g. a gigabit network contracting with a 100Mbps flow. A big difference between sending one 100Mb packet every second and sending 1Kb packet every 10 microsec.

11. Traffic Shaping • Leaky bucket: - Data packets leak from a bucket of depth “sigma” at a rate “rho”. - Network knows that the flow will never inject traffic at a rate higher than “rho” --- incoming traffic is bounded - Easy to implement - Easy for the network to police - Accommodates well fixed-rate flows (“rho” set to rate), but does not accommodate variable-rate (bursty) flows unless “rho” is set to peak rate, which is wasteful

12. Token Bucket • Allows “bounded” burstiness • Tokens generated at rate “rho” are placed in bucket with depth “sigma” • An arriving packet has to remove token(s) to be allowed into the network • A flow can never send more than [sigma + rho * t] over an interval of time t • Thus, the long-term average rate will not exceed rho • More accurate characterization of bursty flows means better management of network resources • Easy to implement, but harder to police • Can add a peak-rate leaky bucket after a token bucket

13. Token Bucket • Example: Flow A always send at 1 MBps ==> rho = 1 MBps, sigma = 1 byte Flow B sends at 0.5 MBps for 2 sec, then at 2 MBps for 1sec, then repeats ==> rho = 1 MBps, sigma = 1 MB We can also this Tspec for Flow A, but that would be an inaccurate characterization

14. Link Scheduling • Challenge: Tspec may change at exit of scheduler (e.g., FCFS) because of interactions among flows • FCFS increases worst-case delay and jitter, so we admit less flows • Solution: non-FCFS scheduler that isolates different flows or classes of flows (hard, soft, best-effort) • Emulate TDM without wasting bandwidth • Virtual Clock provides flows with throughput guarantees and isolation • Idea: use logical (rather than real) time • AR: average data rate required by a flow • When a packet of size P arrives, VC = VC + P/AR • Stamp packet with VC • Transmit packets in increasing order of time stamps • If a flow has twice AR, it will get double a double rate

15. Virtual Clock • If buffer is full, the packet with largest timestamp is dropped • Problem: A flow can save up credits and use them to bump other flows in the future • Fix: when a packet arrives, catch up with real time first VC = MAX (real time, VC) VC = VC + P/AR • Also, if AI is averaging interval, upon receiving AR*AI bytes on this flow, if VC > real time + Threshold, then send advisory to source to reduce its rate

16. WFQ • WFQ provides isolation and delay guarantees • FQ simulates fair bit-by-bit RR by assigning packets priority based on finishing times under bit-by-bit RR - E.g. Flow 1 packets of size 5 and 8, Flow 2 packet of size 10: size 5 first, then size 10, then size 8 • Round number increases at a rate inversely proportional to number of currently active flows • On packet arrival: recompute round number, compute finish number, insert in priority queue, if no space drop packet with largest finish number (max-min fairness) • Approximation error bounded by max_pkt_size / capacity • WFQ can assign different weights to different flows

17. Computing Deterministic Delay Bounds • If flow is shaped by a token bucket (sigma, rho), all routers along the “h”-hop path employ WFQ schedulers, and the flow is assigned a rate of rho at each hop, then end-to-end delay of a packet is bounded by: (sigma / rho) + (h * max_pkt_size / rho) + total approximation error + total propagation delay • A flow is totally isolated, even if other traffic is not shaped at all • Cons: bandwidth and delay are coupled • WFQ does not bound jitter • A non-work-conserving scheduler (e.g., Stop-and-Go, jitter-EDD) may be used to bound jitter

18. Earliest Due Date (EDD) • Unlike WFQ, delay bound is independent of bandwidth requirement • Packet with earliest deadline selected • EDD prescribes how to assign deadlines to packets • Deadline = expected arrival time + delay bound • “Expected” arrival time is the time the packet should arrive according to traffic specification (to deal with bunching of packets downstream) • Delay bound is the smallest feasible bound, computed assuming worst-case arrival pattern from all flows Xmin1 = 10 Xmin2 = 4 3 3 2

19. Bounding jitter • Assume we want to eliminate all jitter • We can achieve this by making the network look like a constant delay line • Idea: At the entry of each switch/router, have a regulator that absorbs delay variations by delaying a packet that arrived ahead of its local deadline at previous switch • Traffic characteristics are preserved as traffic passes through the network • Schedulers with regulators are called “rate-controlled” schedulers • Reduce burstiness within network, thus less buffers needed • Average packet delay is higher than with work-conserving schedulers, but that’s fine for hard real-time traffic

20. Statistical/soft/predictive QoS • Goal: bound the tail of the measure distribution • Not a good idea to use worst-case delay bounds since very few packets (or none!) will actually experience this worst-case delay • Computing statistical bounds (e.g., using effective bandwidths) is usually approximate and often conservative • FIFO+ attempts to reduce worst-case delay and jitter using minimal isolation (and maximal statistical gain) • At each router, a packet is assigned lower priority if it left previous routers ahead of measured average delay, and higher priority if behind average delay

21. Admission Control with Statistical Guarantees • Key idea (law of large numbers): as capacity increases, number of flows that can be supported increases, the probability that a significant number of flows burst simultaneously decreases, so the sum of peak rates can be higher than the available capacity • As the number of flows increases, the capacity allocated to each flow is “effectively” its average rate • Put in enough buffers to make probability of loss low

22. Measurement-based Admission • Key assumption: past behavior is a good indicator of the future • User tells peak rate • If peak rate + measured average rate < capacity, admit • Over time, new call becomes part of average • Can afford to make some errors for predictive (or controlled load) service • Obviously, can admit more calls than admission at peak rate

23. Summary • Performance guarantees can be achieved by combining traffic shaping and scheduling schemes • How good the bounds are? Loose or tight? • How easy to implement these schemes? • What kind of guarantees they provide? • How good is the utilization of the network? • How do clients signal their QoS requirements? • What is the best path to route a flow? • How to achieve QoS for multicast flows and with mobility?

24. RSVP ReSerVation Protocol • Designed to handled multicast flows, where multiple receivers may have different capabilities • RSVP is receiver-initiated, i.e. receiver generates reservation • PATH message tentatively reserves resources, RESV makes reservation (travels as far back up as necessary) • RSVP supports merging of reservations • RSVP is decoupled from routing • PATH and RESV messages periodically sent to refresh state before timeout (i.e. soft state) • Multiple senders can share the same reservation • In contrast, ATM signaling (Q.2931) is sender-initiated, coupled with routing, uses hard state (i.e. explicit delete), and handles only uniform QoS

25. Where to Implement Policies in a Network Topology?Or, QoS Architectures • Key to scaling is to maintain levels of hierarchy: core, distribution, and access • Link speeds should be faster toward the core of the network • Access routers generally do not have to handle high packet switching rates and thus can do complex traffic identification, classification, policing and marking • The overhead of implementing QoS policies in the core would affect a large amount of traffic • Access routers can mark the IP precedence field in the packet header • Core routers simply map precedence to queuing or drop actions • This is similar to the IETF DiffServ architecture (as opposed to the “less scalable” per-flow IETF IntServ architecture)

26. Tension: Scalability versus QoS • Scalability calls for aggregating flows into precedence classes • Also, aggregating destinations results in fewer routing entries, but less granularity of routing decisions • Performing disaggregation gives finer granularity at a higher cost • E.g. more detailed routing advertisments can allow more granular choice of paths that better satisfy QoS requirements • OSPF can advertise multiple costs per link, and compute multiple shortest paths • Or, loose source route through a particular service provider, or multiple addresses/names per host

27. Other QoS Requirements/Issues • Pricing/Billing - can shift demand to off-peak times - charge more during peak hours - rational users help the network by helping themselves • Privacy • Reliability and availability • Operating systems support - reduce costs of data copying, interrupts, … - real-time CPU scheduling, ...