The Evolution of Quality-of- Service on the Internet

Transcription

1 The UNIVERSITY of NORTH CAROLINA at CHAPEL HILL The Evolution of Quality-of- Service on the Internet Kevin Jeffay Department of Computer Science September 15, The Evolution of Quality-of-Service on the Internet End-System Adaptation to Congestion Best-Effort Forwarding Resource (Multicast) Advanced Congestion Control Better-Than- Best-Effort Forwarding Guaranteed QoS Virtual Circuits The quality-of-service issue for the Internet has been debated and researched for at least 20 years The goal has shifted but the assumed gold standard is the realization of virtual circuits Beyond this, everything has been up for grabs Architecture, protocols, networking technologies, 2

2 The Evolution of Quality-of-Service on the Internet End-System Adaptation to Congestion Best-Effort Forwarding Resource (Multicast) Advanced Congestion Control Better-Than- Best-Effort Forwarding Guaranteed QoS Virtual Circuits Architecture debates: Internet centric v. telephony centric In-band versus out of band signaling End-to-end service realization versus hop-by-hop Solve the problem above or below IP? Overprovisioning versus intelligent resource reservation Protocol innovation versus traffic management 3 QoS on the Internet Today What s s the problem? Do we need more bandwidth or just better management of the existing bandwidth? Requirements (performance, scale) insufficient resources sufficient but scarce resources abundant resources Hardware resources in year X 4

3 The Evolution of Quality-of-Service on the Internet End-System Adaptation to Congestion Best-Effort Forwarding Resource (Multicast) Tonight: A historical overview of the efforts to bring QoS to the Internet Visions, architectures, and protocols Take home messages: Advanced Congestion Control Better-Than- Best-Effort Forwarding Guaranteed QoS Virtual Circuits QoS and true internetworking have yet to be married But stay within a managed network and you can have it all Great research has been done but business practices are driving deployment 5 Do we have QoS on the Internet today? PSTN Aggregation Switch/ Depends on who you ask! Any number of enterprise-level voice over IP solutions providers will say yes So why is my skype phone not as good as my cell phone? (Do we care?) 6

4 So what is the QoS problem for the Internet? QoS is the ability to obtain assurances that performance requirements will be met Throughput and delay are the biggies Loss and delay variation are derivative concerns Two dominant views: Assurances can take the form of contractual guarantees (QoS as a finely tunable service), or Assurances represent the performance you d d receive on an unloaded network (QoS as a congestion control problem) Operational distinction: Do we need reservations or will congestion control and adaptation suffice? 7 The Early QoS Debates The Internet circa 1995 Audio Video Throughput (frames/sec) Packet Loss Example: Performance of ProShare TM transmission over the Internet (300 kbps) Frozen video Clipped, broken audio Audio Latency (ms) 8

5 The Early QoS Debates Adaptation versus reservation Video Audio Throughput (frames/sec) Audio Latency (ms) Packet Loss End-system adaptation can ameliorate many of the effects of congestion But can it do so reliably or predictably? (And does it scale?) 9 The Integrated Services Architecture for the Internet (INTSERV) Integrated services introduces the concept of a service model A contract between a sender and the network for a particular quality of service Proposed service models: Guaranteed delay An application receives a guarantee that all packets will be delivered within a fixed delay bound Controlled load Performance equivalent to that on an unloaded network Best-effort effort Same old same old 10

6 Realizing Guaranteed Delay Service Axioms Resource reservation is required Network elements must maintain per- flow state information and use this information to ensure application performance contracts are met Admission control is required To ensure performance contracts are met, network elements must ensure they do not over commit their resources Applications must be policed To ensure performance contracts are met, network elements must ensure applications do not claim more resources than they contracted for 11 Realizing Guaranteed Delay Service Specifying and policing traffic To receive a service contract an application must specify the service it requires and the traffic it will generate Canonical flow specification the token bucket Transmission tokens! " IETF traffic specification (TSpec)! average rate! token bucket depth! peak rate! maximum packet size! minimum policed unit Application data! Regulator!,! max max size Network packets 12

7 Realizing Guaranteed Delay Service Packet forwarding machinery Setup Admission Control & Traffic Control Packet Inter- network Every router reserves and maintains state for every non-best-effort connection 13 Realizing Guaranteed Delay Service Packet forwarding machinery Setup Admission Control & Traffic Control Packet Packet Maps all packets into one or more classes that receive the same service Packet Schedules packets for transmission so that performance contracts are enforced 14

8 Realizing Guaranteed Delay Service Packet forwarding machinery Setup Admission Control & Traffic Control Packet setup protocol Mechanism by which flow-specific state is created and maintained Admission control procedure The decision procedure that is used to determine if a new flow can be accepted or not 15 Realizing Guaranteed Delay Service Packet forwarding machinery Setup Admission Control & Traffic Control Packet End systems must support the same logical components A real-time chain is only as strong as its weakest link 16

9 Integrated Services Architecture Architectural components Setup Admission Control & Traffic Control Packet Flow specifications Resource reservation Admission control Packet scheduling 17 Issues in Resource Point-to-point communications H1 L1 R1 L3 R2 L4 R3 L2 H2 Goal: : Establish a virtual circuit from H1 to H2 Reserve resources in routers R1, R2, and R3 Resources are... Link capacity on transmission links Buffer capacity in routers to hold packets in transit CPU capacity at all routers to forward packets from H1 in real-time 18

10 Resource Example ST-II: Two pass reservation protocol H1 L1 R1 L3 r: H1-H2 R2 L4 R3 L2 H2 r: H1-H2 r: H1-H2 H1 sends a connect message containing a flowspec towards H2 The connect message is modified as needed by R1-R3 Upon receipt of the connect, H2 sends an accept message back to H1 s are made when routers receive the accept message 19 Resource Example ST-II: Two pass reservation protocol H1 L1 R1 r: H1-H2 L5 L3 R4 r: H1-H2 R2 L6 L4 R3 L2 r: H1-H2 H2 What if the route from H1 to H2 changes? How will the application know that the route has changed? What level of integration between routing and resource reservation is appropriate? 20

11 Issues in Resource One-to-many multicast H1 L1 R1 L5 L3 R2 L9 L6 H4 L4 R3 L2 H2 H3 L7 R4 L8 H5 Apply the point-to-point method recursively throughout the multicast tree How do we handle differing link/router capacities? ST-II Reduce all connections to the least common denominator 21 Issues in Resource One-to-many multicast H1 L1 R1 L5 L3 R2 L9 L6 H4 L4 R3 L2 H2 H3 L7 R4 L8 H5 H6 How do we add/delete new users? ST-II Source re-executes the reservation protocol with all receivers 22

12 Issues in Resource One-to-many multicast H1 L1 R1 L5 L3 R2 L9 L6 H4 L4 R3 L2 H2 H3 L7 R4 L8 H5 H1 and H3 independently reserve resources How can we avoid over-reserving resources? 23 Simple Resource Summary H1 L1 R1 L5 L3 R2 L6 L4 R3 L2 H2 R4 Guaranteed service requires integration of resource reservation with routing Sender-initiated reservations do not scale Protocol overhead at sender becomes a bottleneck Difficult to accommodate heterogeneous receivers Low utilization of network links may result from overly conservation reservations 24

13 RSVP A receiver initiated reservation protocol H1 H3 L1 L7 R1 L5 L3 R4 Receivers initiate reservations Receivers know what bandwidth they want or can handle Places burden of joining/leaving on the involved receiver Admits the possibility of optimizing reservations in routers & switches through aggregation state in routers is soft and must be periodically refreshed R2 L9 L6 H4 L4 R3 L8 L2 H5 H2 25 The Integrated Services Architecture Ahead of its time or fatally flawed? Setup Admission Control & Traffic Control Packet FCFS Inter- network 26

14 The Integrated Services Architecture Ahead of its time or fatally flawed? Setup Admission Control & Traffic Control Packet FCFS Guarantees requires per-flow state in every router and switch And guarantees were only modulo route changes Algorithmic complexity of reservations and scheduling is non-trivial Absent a pricing model, why would service providers implement this? Why would providers do this when they can provide these services below IP? 27 The Evolution of Quality-of-Service on the Internet End-System Adaptation to Congestion Best-Effort Forwarding Resource (Multicast) Advanced Congestion Control Better-Than- Best-Effort Forwarding Guaranteed QoS Virtual Circuits The Internet is evolving to support quality-of-service Capacity allocation & inter-flow protection are required for QoS The current mechanisms for realizing QoS are more about router queue management than virtual circuits In the best case, the Internet of tomorrow will provide router forwarding behaviors rather than end-to-end services 28

15 Towards a Better-Than-Best-Effort Service So if guarantees are too much, what s just enough? The IETF controlled load service A service that approximates the service a flow would receive under unloaded conditions in the network In a controlled load service, applications can assume: Setup Admission Control Packet A (very) high percentage of transmitted packets will be delivered A high percentage of transmitted packets will experience a transit delay not significantly greater then the minimum transit delay experienced by any packet 29 Towards a Better-Than-BE Service Architectural principles Shaping Policing Campus Shift in emphasis from per-flow contracts to per-aggregate contracts ( SLAs( SLAs ) All state is maintained at the edges of the network No new state inside a provider s s network A campus aggregates traffic that conforms to a service profile 30

16 Towards a Better-Than-BE Service Architectural principles Shaping Policing Shaping Policing Campus 2 An policies marked traffic to ensure its compliance with the profile An end-user must be able to verify the actual performance it receives Service agreements stitched together from bilateral agreements 31 Towards a Better-Than-BE Service The expected capacity service! " in Marked Packets Unmarked Packets! in In-Profile Unmarked/ Out-of- Profile s allocate capacity for marked flows Campus marks packets for regular or assured service A policer checks arriving flows compliance against profile Conformant in profile packets forwarded unchanged Non-conformant out of profile packets demoted to best-effort 32

17 The Expected Capacity Service Digression: based congestion control FCFS P 1 P 2 P 3 On the Internet today, packet loss is the end-system s s only indication of congestion As switch s s queues overflow, arriving packets are dropped Drop-tail FIFO queuing is the default TCP end-systems detect loss and respond by reducing their transmission rate 33 -Based Congestion Control Active queue management (AQM) FCFS Flip a coinflip Always a coin drop P 1 P 2 P 3 P 4 P 5 P 6 Enqueue Enqueue Key concept: Drop packets before a queue overflows to signal incipient congestion to end-systems Basic mechanism: When the queue length exceeds a threshold, packets are probabilistically dropped Random Early Detection (RED) AQM: Always enqueue if queue length less than a low-water mark Always drop if queue length is greater than a high-water mark Probalistically drop/enqueue if queue length is in between 34

18 Max queue length Max threshold Min threshold Active Queue Management The RED Algorithm queue length Weighted average queue length Time Drop probability Forced drop Probabilistic early drop No drop RED computes a weighted moving average of queue length to accommodate bursty arrivals Drop probability is a function of the current average queue length The larger the queue, the higher the drop probability 35 Active Queue Management The RED Algorithm queue length Max queue length Max threshold Min threshold Weighted average queue length Time Drop probability Forced drop Probabilistic early drop No drop Drop probability 100% max p min th max th Weighted Average Queue Length 36

19 The Expected Capacity Service RED with In/Out (RIO) router runs two RED packet droppers in parallel Apply harsh RED to out-of-profile packets & unmarked packets Apply lenient RED to in-profile packets Out-of-Profile RED In-Profile RED FCFS Campus! 37 The Expected Capacity Service RED with In/Out (RIO) Out-of-Profile RED In-Profile RED FCFS Under RIO, in-profile marked traffic can always occupy at least min th _in queue locations Thus in-profile traffic is allocated at least bandwidth B in = P x min th _in P x max th _out where C is the link capacity and P is the average packet size C 38

20 The Expected Capacity Service Issues Specification of the expected capacity Specification for individual flows or aggregates Specification of the end-point of the service How can a flow ensure that it gets bandwidth to the network it desires? Is one service model enough? Expected capacity service is primarily a throughput service How about a service for latency sensitive applications? 39 The Expected Capacity Service Realizing a premium service The RIO scheme can be extended to provide a premium service Can also be made more resilient to unresponsive flows Regulator Out-of-Profile Non-TCP Traffic RED In-Profile RED FCFS Campus 40

21 The Expected Capacity Service Issues Specification of the expected capacity Specification for individual flows or aggregates Specification of the end-point of the service How can a flow ensure that it gets bandwidth to the network it desires? Is one service model enough? Assured service is primarily a throughput service How about a service for latency sensitive applications? 41 The Two Bit Architecture The expedited forwarding service Shaping High Low Priority Campus s allocate and sell capacity for a premium service Packets are marked and policed according to a service profile Premium service is realized by simple priority scheduling 42

22 The Two Bit Architecture Expedited and assured services Premium marked traffic Assured marked traffic Unmarked besteffort traffic In-Profile RED Out-of-Profile RED Priority The assured (expected capacity) service is easily supported within the low priority queue Packets are marked and policed according to service profiles as before Thus two bits can be used to mark traffic 43 Assured and Expedited Service Comparison! Assured Marked Packets Unmarked Packets In-Profile Assured! in Unmarked/ Out-of- Profile The difference between assured and expedited services is in the way in capacity is allocated and in the way flows are policed Assured capacity is provisioned/policed according to expected demand Premium capacity is provisioned/policed according to peak demand 44

23 Assured and Expedited Service Comparison! Assured Marked Packets Unmarked Packets! In-Profile Assured! in Unmarked/ Out-of- Profile Premium Marked Packets! in Out-of-Profile Premium In-Profile Premium 45 The Expected Capacity Service Issues Specification of the expected capacity Specification for individual flows or aggregates Specification of the end-point of the service How can a flow ensure that it gets bandwidth to the network it desires? Is one service model enough? Assured service is primarily a throughput service How about a service for latency sensitive applications? 46

24 Bandwidth Allocation Signaling issues Shaping Policing Shaping Policing Campus 2 Our conceptual model to date is that s statically configure themselves to offer better-than-best-effort services between themselves End-to-end services realized through bilateral agreements 47 Bandwidth Allocation Signaling issues Shaping Policing Shaping Policing Campus 2 Issues: Identifying flows that are authorized to receive services Communicating and managing state information in border routers Coordinating bandwidth allocation in neighboring networks 48

25 Bandwidth Allocation Bandwidth brokers Policing B B KJ@home -> cs.unc Kbps Shaping Leaf KJ@home -> cs.unc Kbps 9pm-12am Sun-Fri <signature> Leaf Leaf BellSouth P UNC Bandwidth brokers allocate premium/assured bandwidth on the campus and control egress router(s) Assume some signaling protocol exists (e.g.( e.g.,, RSVP) 49 The Expected Capacity Service Where is all this going? The IETF is standardizing a set of router behaviors Called per hop forwarding behaviors (PHBs) Two main PHBs: Assured forwarding (AF) Expedited forwarding (EF) These are part of a larger framework called the differentiated services architecture for the Internet (diffserv) 50

26 Differentiated Services When will we see this stuff deployed? Abilene Premium Service Test Program Launched April 11th, Armonk, NY - To support the QBone, an interdomain quality of service (QoS) testbed initiative sponsored by Internet2, Internet2 announced at the recent Spring 2000 Internet2 Member Meeting the launch of the Abilene Premium Service (APS) test program.... The Qbone/Abilene Premium Service aims to provide a low-loss, lowjitter service to advanced applications. Typically, these are realtime applications that support either human-to-human collaborations or human-to-machine remote control, and demand a level of interactivity that imposes stringent worst-case delay, jitter, and loss requirements on the underlying network service.... The Abilene Premium Service is built on the Expedited Forwarding (EF) per-hop behavior defined by the IETF Differentiated Services working group. The basic packet conditioning and forwarding service is complemented by a measurement infrastructure which will provide detailed QoS performance data to support end-to-end debugging and analysis of QoS-enabled paths End-System Adaptation to Congestion Best-Effort Forwarding The Evolution of Quality-of-Service on the Internet Resource (Multicast) Advanced Congestion Control Better-Than- Best-Effort Forwarding Capacity allocation & isolation are required for better- than best effort services But it need not be on a per-flow basis (maybe!) Key principle: Keep state only at the edges of the network Research community has focused on standardizing forwarding behaviors rather than services Guaranteed QoS Virtual Circuits 52