Quality of Service in the Internet Theory and Practice

1. Quality of Service in the Internet Theory and Practice Geoff Huston

2. Acknowledgment and thanks to Fred Baker and Paul Ferguson, both of Cisco Systems, for some of the material used in this slide set 2

3. Agenda • Definition of the Problem • Service Quality and the Application Environment • Approaches to Quality Management • Considerations • Mechanisms • Measuring QoS • Marketing QoS • Summary 3

4. Quality of Service Definition of the Problem 4

5. What is the problem? • Today’s Internet is plagued by sporadic poor performance. This is getting worse, not better! • Methods are needed to differentiate traffic and provide “services” 5

6. What is the problem? • “Poor Performance” of the Internet service environment • more specifically: • routing instability • high packet loss in critical NAPs/Exchange Points • server congestion • high variation of transaction times • poor protocol performance due to loss and round trip time variation 6

7. The QoS challenge • Internet network infrastructure is under stress due to: • robust demand models • engineering the network to use all available resources, on the edge of instability and capacity saturation

8. What is the problem? • Applications are more demanding • end systems are getting faster • end systems use faster network connections • emerging ubiquity of access breeds diversity of application requirements • end systems applications wish to negotiate performance from the network 7

9. It would be good if… • When the user wished to access a priority service: • the network could honor the request • The application could forecast its network load requirements so that: • the network could commit to meet them • When there isn't sufficient bandwidth on one network path to meet the application’s requirements: • The network could find another path 8

10. Quality of Service • Customers want access to an Internet service which can provide a range of consistent & predictable high quality service levels • in addition to normal best effort service levels 9

11. Quality of Service • Network mechanisms intended to meet this demand for various levels of service are categorized within the broad domain of Quality of Service

12. Rationale for providing QoS • The Internet is commercial & competitive. • No major revelation here • Internet Service Providers are looking for ways to generate new sources of revenue. • Again, nothing new • Creation of new services creates new sources of revenue. 10

13. Rationale for providing QoS • Preferential treatment is an attractive service which customers are indicating they desire to purchase. 11

14. Rationale for providing QoS • Service Providers would like offer differential services where: • the customer is charged at a rate comparable to service level expectations • where the marginal service revenue reflects the marginal network engineering and support costs for the service 12

15. Non-Rationale for QoS • QoS is not a tool to compensate for inadequacies elsewhere in the network. • It will not fix: • Massive over-subscription • Horrible congestion situations • Sloppy network design No magic here™ 13

16. What is the expectation? • A requirement for a premium differentiated services within the network that will provide predictable and consistent service response for selected customers and traffic flows: • provision of guarantees on bandwidth & delay • provision of absolute service level agreements • provision of average service level agreements But can the Internet deliver? 14

17. QoS • QoS is the provision of control mechanisms within the network which are intended to manage congestion events. 15

18. Aside... • The Congestion Problem as we see it -- • Chaos theory: • Congestion is non-linear behavior • Think in terms of pipes and water • Turbulence produces mixing and increases drag • QoS is akin to solving non-linear fluid dynamics: • Enforcing linearity, or • Convincing big flows to behave nicely 16

19. Expectation setting QoS is not magic • QoS cannot offer cures for a poorly performing network • QoS does not create nonexistent bandwidth. • Elevating the amount of resources available to one class of traffic decreases the amount available for other traffic classes • Total goodput will be reduced in a differentiated environment • QoS will not alter the speed of light • On an unloaded network, QoS mechanisms will not make the network any faster • Indeed, it could make it slightly worse! 17

20. Expectation setting QoS is unfair damage control • QoS mechanisms attempt to preferentially allocate resources to predetermined classes of traffic, when the resource itself is under contention • The preferential allocation can be wasteful, making the cumulative damage worse • Resource management only comes into play when the resource is under contention by multiple customers or traffic flows • Resource management is irrelevant when the resource is idle or not an object of contention 18

21. Expectation setting QoS is relative, not absolute • QoS actively discriminates between preferred and non-preferred classes of traffic at those times when the network is under load (congested) • Qos is the relative difference in service quality between the two generic traffic classes • If every client used QoS, then the net result is a zero sum gain 19

22. Expectation setting QoS is intentionally elitist and unfair • The QoS relative difference will be greatest when the preferred traffic class is a small volume compared to the non-preferred class • QoS preferential services will probably be offered at a considerable price premium to ensure that quality differentiation is highly visible 20

23. Quality of Service Definition of Quality 21

24. What is Quality? • Quality cannot be measured on an entire network • Flow bandwidth is dependant on the chosen transit path • Congestion conditions are a localized event • Quality metrics degrade for those flows which transit the congested location • Quality can be only be measured on an end-to-end traffic flow, at a particular time 22

25. Quality metrics • The network quality metrics for a flow are: • Delay - the elapsed time for a packet to transit the network • Jitter - the variation in delay for each packet • Bandwidth - the maximal data rate that is available for the flow • Reliability - the rate of packet loss, corruption, and re-ordering within the flow 23

26. Quality metrics • Quality metrics are amplified by network load • Delay increases due to increased queue holding times • Jitter increases due to chaotic load patterns • Bandwidth decreases due to increased competition for access • Reliability decreases due to queue overflow, causing packet loss 24

27. QoS and the Internet • The Internet transmission model is a set of self-adjusting traffic flows that cooperate to efficiently load the network transmission circuits • session performance is variable • network efficiency is optimised

28. QoS and the Internet • QoS is a requirement for the network to bias the flow self-adjustment to allow some flows to consume greater levels of the network resource • this is not easy...

29. Quality metrics • Quality differentiation is only highly visible under heavy network load • differentiation is relative to normal best effort • On unloaded networks queues are held short, reducing queue holding time, propagation delay is held constant and the network service quality is at peak attainable level 25

30. The Internet QoS Marginis small QoS differential for a given load 1 Quality traffic efficiency Network Carriage Efficiency Best Effort traffic efficiency You must be joking Network Load

31. Service Quality Not every network is designed with quality in mind… • Adherence to fundamental networking engineering principals. • Operate the network to deliver Consistency, Stability, Availability, and Predictability. • Cutting corners is not necessarily a good idea. 26

32. Service Quality Without Service Quality, QoS is unachievable 27

33. Quality of ServiceService Qualityand the Application EnvironmentApplication Performance Issues 28

34. Today’s Internet Load • Two IP protocol families • TCP • UDP • Three common application elements • WWW page fetches (TCP) • bulk data transfer (TCP) • audio & video transfer (UDP) consume some 90% of today’s Internets 29

35. UDP-based applications • sender transmits according to external signal source timing, such as: • audio encoder • video encoder • one (unicast) or more (multicast) receivers • no retransmission in response to network loss • need to maintain integrity of external clocking of signal • no rate modification due to network congestion effects • no feedback path from network to encoder 30

36. UDP and Quality • QoS: reduce loss, delay and jitter • RSVP approach • ‘reserve’ resource allocation across intended network path • guaranteed load for constant traffic rate encoder • controlled load for burst rate managed encoder • application-based approach • introduce feedback path from receiver(s) to encoder to allow for some rate adjustment within the encoder • diff-serv approach • mark packets within a flow to trigger weighted preferential treatment 31

37. TCP behavior • Large volume TCP transfers • allow the data rate to adjust to the network conditions • establish point of network efficiency, then probe it • variable rate continually adjusted to optimize network load at the point of maximal transfer without loss • uses dynamic adjustment of sending window to vary the amount of data held ‘in flight’ within the network 32

38. TCP performance use the Principle of Network Efficiency: • only inject more data into a loaded network when you believe that the receiver has removed the same amount of data from the network • TCP uses ACKs as the sender’s timer Data packets R S ACK packets 33

39. TCP rate control (1) • Slow Start • inject one segment into the network, wait for ACK • for each ACK received inject ACK’ed data quantity, plus an additional segment (exponential rate growth) • continue until fast packet loss, then switch to Congestion Avoidance Under slow start TCP window growth is exponential 34

40. TCP rate control (2) • Congestion Avoidance • halve current window size • for each ACK received inject ACK’d data quantity plus message_segment / RTT additional data (linear rate growth of 1 segment per RTT) • on fast loss, halve current window size Under Congestion Avoidance TCP window size is a linear sawtooth 35

41. TCP session behaviour Network congestion level Slow Start Behaviour Congestion Avoidance Behaviour 36

42. TCP and Quality • For long held sessions an optimal transfer rate is dependant on: • avoiding sequenced packet drop, to allow TCP fast retransmit algorithm to trigger • i.e., tail drop is a Bad Thing ™ • avoiding false network load signals, to allow slow start to reach peak point of path load (ATM folk please take careful note!) • congestion avoidance has (slow) linear growth while slow start uses (faster) exponential growth • avoiding resonating cyclical queue pressure • packets tend to cluster at RTT epoch intervals, needing large queues to even out load at bottleneck spots 37

43. Short TCP sessions • average WWW session is 15 packets • 15 packets are 4 RTTs under slow start • average current network load is 70% WWW traffic • performance management for short TCP sessions is important today 38

44. Short TCP and Quality • Increase initial slow start TCP window from 1 to 4 segments • decrease transfer time by 1 RTT for 15 packet flows • avoid loss for small packet sequences • retransmission has proportionately high impact on transfer time • use T/TCP to avoid 3-way handshake delay • reduce transfer time from 6 RTT to 4 RTT • use HTTP/1.1 to avoid multiple short TCP sessions 39

45. TCP and QoS • TCP performance is based on round trip path • Partial QoS measures may not improve TCP performance • QoS symmetry • End-to-end QoS 40

46. QoS Symmetry • Forward (data) precedence without reverse (ACK) precedence may not be enough for TCP • data transmission is based on integrity of reverse ACK timing • unidirectional QoS setting is not necessarily enough for TCP • ACKs should mirror the QoS of the data it acknowledges to ensure optimal performance differential • will the network admit such ‘remote setting’ QoS? How? • will the QoS tariff mechanism support remote triggered QoS? How? 41

47. End-to-End QoS • Precedence on only part of the end-to-end path may not be enough • data loss and jitter introduced on non-QoS path component may dominate end-to-end protocol behavior 42

48. End-To-End QoS • Partial provider QoS is not good enough • inter-provider QoS agreements an essential precondition for Internet-wide QoS • inter-provider QoS agreements must cover uniform semantics of QoS indicators • inter-provider agreements are not adequately robust today to encompass QoS 43

49. What is End-to-End? 44

50. QoS Discovery protocol • Will we require QoS discovery probes to ‘uncover’ QoS capability on a path to drive around the non-uniform deployment environment? • similar to MTU discovery mechanism used to uncover end-to-end MTU • use probe mechanism to uncover maximal attainable QoS setting on end-to-end path • even if we need it, we haven’t got one of these tools yet! 45