Computer Networks II

Transcription

1 Computer Networks II QoS: Techniques and Architectures Giorgio Ventre COMICS LAB Dipartimento di Informatica e Sistemistica Università di Napoli Federico II Nota di Copyright Quest insieme di trasparenze è stato ideato e realizzato dai ricercatori del Gruppo di Ricerca sull Informatica Distribuita del Dipartimento di Informatica e Sistemistica dell Università di Napoli e del Laboratorio Nazionale per la Informatica e la Telematica Multimediali. Esse possono essere impiegate liberamente per fini didattici esclusivamente senza fini di lucro, a meno di un esplicito consenso scritto degli Autori. Nell uso dovrà essere esplicitamente riportata la fonte e gli Autori. Gli Autori non sono responsabili per eventuali imprecisioni contenute in tali trasparenze né per eventuali problemi, danni o malfunzionamenti derivanti dal loro uso o applicazione. 1

2 Overview Why better-than-best-effort (QoS-enabled) Internet? Quality of Service (QoS) building blocks End-to-end protocols: RTP, H.323 Network protocols:» Integrated Services(IntServ), RSVP.» Scalable differentiated services: DiffServ Control plane: QoS routing, traffic engineering, policy management, pricing models Why Better-than-Best-Effort (QoS)? To support a wider range of applications» Real-time, Multimedia, etc To develop sustainable economic models and new private networking services» Current flat priced models, and best-effort services do not cut it for businesses 2

3 Quality of Service: What is it? Multimedia applications: network audio and video QoS network provides application with level of performance needed for application to function. What is QoS? Better performance as described by a set of parameters or measured by a set of metrics. Generic parameters:» Bandwidth» Delay, Delay-jitter» Packet loss rate (or loss probability) Transport/Application-specific parameters:» Timeouts» Percentage of important packets lost 3

4 What is QoS (contd)? These parameters can be measured at several granularities:» micro flow, aggregate flow, population. QoS considered better if» a) more parameters can be specified» b) QoS can be specified at a fine-granularity. QoS spectrum: Best Effort Leased Line Fundamental Problems FIFO Scheduling Discipline B B In a FIFO service discipline, the performance assigned to one flow is convoluted with the arrivals of packets from all other flows!» Can t get QoS with a free-for-all» Need to use new scheduling disciplines which provide isolation of performance from arrival rates of background traffic 4

5 Fundamental Problems Conservation Law (Kleinrock): (i)w q (i) = K Irrespective of scheduling discipline chosen:» Average backlog (delay) is constant» Average bandwidth is constant Zero-sum game => need to set-aside resources for premium services QoS Big Picture: Control/Data Planes Control Plane: Signaling + Admission Control or SLA (Contracting) + Provisioning/Traffic Engineering Router Workstation Router Internetwork or WAN Router Workstation Data Plane: Traffic conditioning (shaping, policing, marking etc) + Traffic Classification + Scheduling, Buffer management 5

6 QoS Components QoS => set aside resources for premium services QoS components:» a) Specification of premium services: (service/service level agreement design)» b) How much resources to set aside? (admission control/provisioning)» c) How to ensure network resource utilization, do load balancing, flexibly manage traffic aggregates and paths? (QoS routing, traffic engineering) QoS Components (Continued)» d) How to actually set aside these resources in a distributed manner? (signaling, provisioning, policy)» e) How to deliver the service when the traffic actually comes in (claim/police resources)? (traffic shaping, classification, scheduling)» f) How to monitor quality, account and price these services? (network mgmt, accounting, billing, pricing) 6

7 How to upgrade the Internet for QoS? Approach: de-couple end-system evolution from network evolution End-to-end protocols: RTP, H.323 etc to spur the growth of adaptive multimedia applications» Assume best-effort or better-than-best-effort clouds Network protocols: IntServ, DiffServ, RSVP, MPLS, COPS» To support better-than-best-effort capabilities at the network (IP) level QOS SPECIFICATION, TRAFFIC, SERVICE CHARACTERIZATION, BASIC MECHANISMS 7

8 Service Specification Loss: probability that a flow s packet is lost Delay: time it takes a packet s flow to get from source to destination Delay jitter: maximum difference between the delays experienced by two packets of the flow Bandwidth: maximum rate at which the soource can send traffic QoS spectrum: Best Effort Leased Line Hard Real Time: Guaranteed Services Service contract» Network to client: guarantee a deterministic upper bound on delay for each packet in a session» Client to network: the session does not send more than it specifies Algorithm support» Admission control based on worst-case analysis» Per flow classification/scheduling at routers 8

9 Soft Real Time: Controlled Load Service Service contract:» Network to client: similar performance as an unloaded best-effort network» Client to network: the session does not send more than it specifies Algorithm Support» Admission control based on measurement of aggregates» Scheduling for aggregate possible Traffic and Service Characterization To quantify a service one has two know» Flow s traffic arrival» Service provided by the router, i.e., resources reserved at each router Examples:» Traffic characterization: token bucket» Service provided by router: fix rate and fix buffer space Characterized by a service model (service curve framework) 9

10 Token Bucket Characterized by three parameters (b, r, R)» b token depth» r average arrival rate» R maximum arrival rate (e.g., R link capacity) A bit is transmitted only when there is an available token» When a bit is transmitted exactly one token is consumed r tokens per second bits b tokens b*r/(r-r) slope R slope r <= R bps regulator time Characterizing a Source by Token Bucket Arrival curve maximum amount of bits transmitted by time t Use token bucket to bound the arrival curve bps bits Arrival curve time time 10

11 Example Arrival curve maximum amount of bits transmitted by time t Use token bucket to bound the arrival curve bits (b=1,r=1,r=2) Arrival curve bps time size of time interval Per-hop Reservation Given b,r,r and per-hop delay d Allocate bandwidth r a and buffer space B a such that to guarantee d slope r a bits slope r Arrival curve b d B a 11

12 What is a Service Model? external process offered traffic Network element (connection oriented) delivered traffic The QoS measures (delay,throughput, loss, cost) depend on offered traffic, and possibly other external processes. A service model attempts to characterize the relationship between offered traffic, delivered traffic, and possibly other external processes. Arrival and Departure Process R in Network Element R out bits R in (t) = arrival process = amount of data arriving up to time t delay buffer R out (t) = departure process = amount of data departing up to time t t 12

13 Traffic Envelope (Arrival Curve) Maximum amount of service that a flow can send during an interval of time t b(t) = Envelope slope = max average rate Burstiness Constraint slope = peak rate t Service Curve Assume a flow that is idle at time s and it is backlogged during the interval (s, t) Service curve: the minimum service received by the flow during the interval (s, t) 13

14 Big Picture bits bits Service curve R in (t) slope = C bits t t R out (t) t Delay and Buffer Bounds bits E(t) = Envelope Maximum delay Maximum buffer S (t) = service curve t 14

15 Mechanisms: Traffic Shaping/Policing Token bucket: limits input to specified Burst Size (b) and Average Rate (r).» Traffic sent over any time T <= r*t + b» a.k.a Linear bounded arrival process (LBAP) Excess traffic may be queued, marked BLUE, or simply dropped Mechanisms: Queuing/Scheduling Traffic Sources $$$$$$ $$$ $ Traffic Classes Class A Class B Class C Use a few bits in header to indicate which queue (class) a packet goes into (also branded as CoS) High $$ users classified into high priority queues, which also may be less populated => lower delay and low likelihood of packet drop Ideas: priority, round-robin, classification, aggregation,... 15

16 Mechanisms: Buffer Mgmt/Priority Drop Drop RED and BLUE packets Drop only BLUE packets Ideas: packet marking, queue thresholds, differential dropping, buffer assignments SCHEDULING 16

17 Packet Scheduling Decide when and what packet to send on output link» Usually implemented at output interface flow 1 1 Classifier flow 2 Scheduler 2 flow n Buffer management Focus: Scheduling Policies Priority Queuing: classes have different priorities; class may depend on explicit marking or other header info, eg IP source or destination, TCP Port numbers, etc. Transmit a packet from the highest priority class with a non-empty queue Preemptive and non-preemptive versions 17

18 Scheduling Policies (more) Round Robin: scan class queues serving one from each class that has a non-empty queue Round-Robin Discussion Advantages: protection among flows» Misbehaving flows will not affect the performance of well-behaving flows Misbehaving flow a flow that does not implement any congestion control» FIFO does not have such a property Disadvantages:» More complex than FIFO: per flow queue/state» Biased toward large packets each flow receives service proportional to the number of packets it sends (multiplied by the bytes carried by packets). 18

19 Generalized Processor Sharing(GPS) Assume a fluid model of traffic» Visit each non-empty queue in turn (RR)» Serve infinitesimal from each» Leads to max-min fairness GPS is un-implementable!» We cannot serve infinitesimals, only packets Weighted Fair Rate in GPS A work conserving GPS is defined as Wi ( t, t dt) W ( t, t dt) w w i j B( t) j i B( t) where» w i weight of flow i» W i (t 1, t 2 ) total service received by flow i during [t 1, t 2 )» W(t 1, t 2 ) total service allocated to all flows during [t 1, t 2 )» B(t) number of flows backlogged 19

20 Weighted Fair Rate Computation in GPS Associate a weight w i with each flow i If link congested, compute f such that Bit x bit Round Robin min( ri, f wi ) C i (w 1 = 3) 8 (w 2 = 1) 6 (w 3 = 1) f = 2: min(8, 2*3) = 6 min(6, 2*1) = 2 min(2, 2*1) = 2 Bit-by-bit Round Robin when dealing with Packets Single flow: clock ticks when a bit is transmitted. For packet i:» P i = length, A i = arrival time, S i = begin transmit time, F i = finish transmit time» F i = S i +P i = max (F i-1, A i ) + P i Multiple flows: clock ticks when a bit from all active flows is transmitted round number» Can calculate F i for each packet if number of flows is known at all times This can be complicated 20

21 Packet Approximation of Fluid System Standard techniques of approximating fluid GPS» Select packet that finishes first in GPS assuming that there are no future arrivals Important properties of GPS» Finishing order of packets currently in system independent of future arrivals Implementation based on virtual time» Assign virtual finish time to each packet upon arrival» Packets served in increasing order of virtual times Fair Queuing (FQ) Idea: serve packets in the order in which they would have finished transmission in the fluid flow system Mapping bit-by-bit schedule onto packet transmission schedule Transmit packet with the lowest F i at any given time Variation: Weighted Fair Queuing (WFQ) 21

22 Approximating GPS with WFQ Fluid GPS system service order Weighted Fair Queueing» select the first packet that finishes in GPS FQ Example Flow 1 Flow 2 Output F=10 F=8 F=5 Flow 1 (arriving) Flow 2 transmitting Output Cannot preempt packet currently being transmitted F=10 F=2 22

23 Throughput(Mbps) Throughput(Mbps) FQ Advantages FQ protect well-behaved flows from ill-behaved flows Example: 1 UDP (10 Mbps) and 31 TCP s sharing a 10 Mbps link RED Flow Number FQ Flow Number Big Picture FQ does not eliminate congestion it just manages the congestion You need both end-host congestion control and router support for congestion control» end-host congestion control to adapt» router congestion control to protect/isolate Don t forget buffer management: you still need to drop in case of congestion. Which packet s would you drop in FQ?» one possibility: packet from the longest queue 23

24 Parekh-Gallager theorem Let a connection be allocated weights at each WFQ scheduler along its path, so that the least bandwidth it is allocated is g Let it be leaky-bucket regulated such that # bits sent in time [t 1, t 2 ] <= g(t 2 - t 1 ) + Let the connection pass through K schedulers, where the kth scheduler has a rate r(k) Let the largest packet size in the network be P end _ to _ end _ delay / g K 1 P / g K k 1 k 1 P / r( k) Significance P-G Theorem shows that WFQ scheduling can provide end-to-end delay bounds in a network of multiplexed bottlenecks» WFQ provides both bandwidth and delay guarantees» Bound holds regardless of cross traffic behavior (isolation)» Needs shapers at the entrance of the network Can be generalized for networks where schedulers are variants of WFQ, and the link service rate changes over time 24

25 QoS ARCHITECTURES Stateless vs. Stateful QoS Solutions Stateless solutions routers maintain no fine grained state about traffic scalable, robust weak services Stateful solutions routers maintain per-flow state powerful services guaranteed services + high resource utilization fine grained differentiation protection much less scalable and robust 25

26 Existing Solutions QoS Network support for congestion control Stateful Tenet [Ferrari & Verma 89] IntServ [Clark et al 91] ATM [late 80s] Round Robin [Nagle 85] Fair Queueing [Demers et al 89] Flow Random Early Drop (FRED) [Lin & Morris 97] Stateless DiffServ - [Clark & Wroclawski 97] - [Nichols et al 97] DecBit [Ramkrishnan & Jain 88] Random Early Detection (RED) [Floyd & Jacobson 93] BLUE [Feng et al 99] REM [Low at al 00] Integrated Services (IntServ) An architecture for providing QOS guarantees in IP networks for individual application sessions Relies on resource reservation, and routers need to maintain state information of allocated resources (eg: g) and respond to new Call setup requests 26

27 Signaling semantics Classic scheme: sender initiated SETUP, SETUP_ACK, SETUP_RESPONSE Admission control Tentative resource reservation and confirmation Simplex and duplex setup; no multicast support RSVP: Internet Signaling Creates and maintains distributed reservation state De-coupled from routing:» Multicast trees setup by routing protocols, not RSVP (unlike ATM or telephony signaling) Receiver-initiated: scales for multicast Soft-state: reservation times out unless refreshed Latest paths discovered through PATH messages (forward direction) and used by RESV mesgs (reverse direction). 27

28 Call Admission Session must first declare its QoS requirement and characterize the traffic it will send through the network R-spec: defines the QoS class assigned T-spec: defines the traffic characteristics A signaling protocol is needed to carry the R-spec and T-spec to the routers where reservation is required; RSVP is a leading candidate for such signaling protocol Call Admission Call Admission: routers will admit calls based on their R-spec and T-spec and based on the current resource allocated at the routers to other calls. 28

29 Stateful Solution: Guaranteed Services Achieve per-flow bandwidth and delay guarantees» Example: guarantee 1MBps and < 100 ms delay to a flow Sender Receiver Stateful Solution: Guaranteed Services Allocate resources - perform per-flow admission control Sender Receiver 29

30 Stateful Solution: Guaranteed Services Install per-flow state Sender Receiver Stateful Solution: Guaranteed Services Challenge: maintain per-flow state consistent Sender Receiver 30

31 Per-flow classification Stateful Solution: Guaranteed Services Sender Receiver Stateful Solution: Guaranteed Services Per-flow buffer management Sender Receiver 31

32 Stateful Solution: Guaranteed Services Per-flow scheduling Sender Receiver Stateful Solution Complexity Data path» Per-flow classification» Per-flow buffer management» Per-flow scheduling Control path» install and maintain per-flow state for data and control paths Classifier Per-flow State flow 1 flow 2 flow n Buffer management Scheduler output interface 32

33 Stateless vs. Stateful Stateless solutions are more» scalable» robust Stateful solutions provide more powerful and flexible services» guaranteed services + high resource utilization» fine grained differentiation» protection Question Can we achieve the best of two worlds, i.e., provide services implemented by stateful networks while maintaining advantages of stateless architectures?» Yes, in some interesting cases. DPS, CSFQ. Can we provide reduced state services, I.e., maintain state only for larger granular flows rather than end-to-end flows?» Yes: Diff-serv 33

34 Differentiated Services (DiffServ) Intended to address the following difficulties with Intserv and RSVP; Scalability: maintaining states by routers in high speed networks is difficult due to the very large number of flows Flexible Service Models: Intserv has only two classes, want to provide more qualitative service classes; want to provide relative service distinction (Platinum, Gold, Silver, ) Simpler signaling: (than RSVP) many applications and users may only want to specify a more qualitative notion of service Differentiated Services Model Ingress Edge Router Interior Router Egress Edge Router Edge routers: traffic conditioning (policing, marking, dropping), SLA negotiation» Set values in DS-byte in IP header based upon negotiated service and observed traffic. Interior routers: traffic classification and forwarding (near stateless core!)» Use DS-byte as index into forwarding table 34

35 Diffserv Architecture Edge router: - per-flow traffic management - marks packets as inprofile and out-profile Core router: b r marking scheduling. - per class TM - buffering and scheduling based on marking at edge - preference given to in-profile packets - Assured Forwarding Packet format support Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6: renamed as DS 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive 2 bits are currently unused 35

36 Traffic Conditioning It may be desirable to limit traffic injection rate of some class; user declares traffic profile (eg, rate and burst size); traffic is metered and shaped if non-conforming Per-hop Behavior (PHB) PHB: name for interior router data-plane functions» Includes scheduling, buff. mgmt, shaping etc Logical spec: PHB does not specify mechanisms to use to ensure performance behavior Examples:» Class A gets x% of outgoing link bandwidth over time intervals of a specified length» Class A packets leave first before packets from class B 36

37 PHB (contd) PHBs defined:» Expedited Forwarding: departure rate of packets from a class equals or exceeds a specified rate (logical link with a minimum guaranteed rate) Emulates leased-line behavior» Assured Forwarding: 4 classes, each guaranteed a minimum amount of bandwidth and buffering; each with three drop precedence partitions Emulates frame-relay behavior Scalable Core (SCORE) A trusted and contiguous region of network in which» edge nodes perform per flow management» core nodes do not perform per flow management edge nodes core nodes edge nodes 37

38 SLA Definitions Today SLA statistical definitions do matter» min/avg/max versus percentile» Measured time interval» interval between probes» Point-to-point vs. point-to-multipoint vs. multipointto-multipoint SLAs definitions today tend to be loose» averaged over a month» averaged over many POP-to-POP pairs (temptation to add short pairs to reduce average )» Round-trip Deploying Tight-SLA services on an IP Backbone Number of tools are available to enable tight SLA services to be offered» Physical network design and topology» Diffserv: per-hop congestion management Applying differential queuing and scheduling mechanism to implement a differentiated SLA scheme» Capacity planning and active monitoring» Tuning IGP Convergence slow convergence upon link/node failure directly impacts SLAs 38

39 Deploying Tight-SLA services on an IP Backbone Number of tools are available to enable tight SLA services to be offered (contd )» Traffic engineering: avoid aggregation on shortest path IP aggregation on the shortest path can cause sub optimal use of resources, and can impact SLAs» Fast ReRoute (FRR) Protection FRR can be used to protect key resources and provide rapid restoration for tight SLAs The key for controlling Loss, Latency and Jitter: Provisioning! The service that traffic receives is dependent upon the ratio of traffic load to available capacity More Bandwidth (offer) than traffic (demand) means» Low loss» Low Latency» Low Jitter 39

40 Over-Provisioned Backbone Over provision by ~2x the max. aggregate traffic load» Refs: {BONALD, CASNER, CHARNY} Over-provisioning (Source: Stephen Casner, Packet Design, NANOG 22) Jitter Measurement Summary for the Week 69 million packets transmitted Zero packets lost 100% jitter < 700 s 40

41 Over-provisioned Backbone Effective Simple» Available bandwidth > aggregate traffic demand» QoS mechanisms kept at to edge» Network is simple to design, deploy and operate Overprovisioned Backbone - Drawback Risk related to provisioning failure No service isolation» VPN, VoIP, Internet: same fate! Expensive» design for the aggregate!!!» Internet receives the same quality as VoIP 41

42 Not every week is like this (Source: Stephen Casner, Packet Design, NANOG 22) 99.99% Over-provisioning Expensive Aggregate bandwidth overprovision comes at a cost, however:» e.g. 150Mbps of VoIP and 1.5Gbps of data between two POPs» 1.65Gbps of aggregate load» requires 3.3Gbps of bandwidth for 2x over-provisioning» typically provisioned using 2x STM16/OC48» hence 5Gbps of bandwidth used to support 1.65Gbps aggregate load with 150Mbps of low delay, low jitter, low loss traffic 42

43 Over-provisioning Expensive Over-provisioning Expensive 43