* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download ECE544Lec7QoSDR06
Survey
Document related concepts
IEEE 802.1aq wikipedia , lookup
Serial digital interface wikipedia , lookup
Cellular network wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
TCP congestion control wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Real-Time Messaging Protocol wikipedia , lookup
Leaky bucket wikipedia , lookup
Deep packet inspection wikipedia , lookup
Transcript
ECE544: Communication Networks-II, Spring 2006 D. Raychaudhuri & Max Ott Lecture 7 Includes teaching materials from L. Peterson Today’s Lecture • Quality-of-service (QoS) in IP and ATM Today’s Lecture • Quality-of-service (QoS) in IP and ATM Congestion Control • Mechanisms to prevent overload on the network and hence maintain QoS – End-to-end flow control (e.g. TCP) – Hop-by-hop flow control (e.g. ECN) – Packet scheduling at each network element Network Congestion • All networks have saturating throughput – Reduction in performance beyond max capacity – Need to keep input load below G0 Smax Thru Capacity Limit Traffic margin Overload region Congestion control policies Normal operating Point (G0) Offered Traffic (G) Queue Scheduling • A queue scheduler employs 2 strategies: – Which packet to serve (transmit) next – Which packet to drop next (when required) FIFO Queuing • FIFO:first-in-first-out (or FCFS: firstcome-first-serve) • Arriving packets get dropped when queue is full regardless of flow or importance - implies drop-tail • Important distinction: – FIFO: scheduling discipline – Drop-tail: drop policy Fair Queuing • Main idea: – maintain a separate queue for each flow currently flowing through router – router services queues in Round-Robin fashion FQ illustration Flow 1 Flow 2 I/P O/P Flow n Variation: Weighted Fair Queuing (WFQ) Some Complications • Packets are of different length • We really need bit-by-bit round-robin • FQ simulates bit-by-bit RR – Not feasible to interleave bits! Max-min Fairness • Allocate user with “small” demand what it wants, evenly divide unused resources to “big” users • Formally: • Resources allocated in terms of increasing demand • No source gets resource share larger than its demand • Sources with unsatisfied demands get equal share of resource Max-min Fairness Example • Assume sources 1..n, with resource demands X1..Xn in ascending order. Assume channel capacity C. – Give C/n to X1; if this is more than X1 wants, divide excess (C/n - X1) to other sources: each gets C/n + (C/n - X1)/(n-1) – If this is larger than what X2 wants, repeat process • Bit-by-bit RR achieves max-min fairness Bit-by-bit RR • Single flow: suppose clock ticks when a bit is transmitted. For packet i: – Pi: length, Ai = arrival time, Si: begin transmit time, Fi: finish transmit time. Fi = Si+Pi – Fi = max (Fi-1, Ai) + Pi • Multiple flows: clock ticks when a bit from all active flows is transmitted – calculate Fi for each packet Bit-by-bit RR example Flow 1 Flow 2 Output F=10 F=8 F=5 Flow 1 (arriving) Cannot preempt packet currently being transmitted F=10 F=2 Flow 2 Output transmitting Congestion Avoidance • We have seen TCP’s approach: – Detect congestion after it happens – Increase load trying to maximize utilization until loss occurs • Alternatively: – We can try to predict congestion and reduce rate before loss occurs – This is called congestion avoidance Router Congestion Notification • Router has unified view of queuing behavior • Routers can distinguish between propagation and persistent queuing delays • Routers can decide on transient congestion, based on workload Random Early Detection (RED) • Motivation: – High bw-delay flows have large queues to accommodate transient congestion – TCP detects congestion from loss - after queues have built up and increase delay • Aim: – Keep throughput high and delay low – Accommodate bursts Other Options • Random drop: – Packet arriving when queue is full causes some random packet to be dropped • Drop front: – On full queue, drop packet at head of queue • Random drop and drop front solve the lock-out problem but not the fullqueues problem Solving the Full Queues Problem • Drop packets before queue becomes full (early drop) • Intuition: notify senders of incipient congestion – Example: early random drop (ERD): • If qlen > drop level, drop each new packet with fixed probability p • Does not control misbehaving users Random Early Detection (RED) • Detect incipient congestion, allow bursts • Keep power (throughput/delay) high – keep average queue size low – assume hosts respond to lost packets • Avoid window synchronization – randomly mark packets • Avoid bias against bursty traffic • Some protection against ill-behaved RED Algorithm • Maintain running average of queue length • If avg < minth do nothing – Low queuing, send packets through • If avg > maxth, drop packet – Protection from misbehaving sources • Else mark packet in a manner proportional to queue length – Notify sources of incipient congestion RED Operation Min thresh Max thresh Average queue length P(drop) 1.0 MaxP Avg length minthresh maxthresh Quality of Service Outline Realtime Applications Integrated Services Differentiated Services Realtime Applications • Require “deliver on time” assurances – must come from inside the network Microphone Sampler, A D converter Buffer, D A Speaker – Example application (audio) – – – – sample voice once every 125us each sample has a playback time packets experience variable delay in network add constant factor to playback time: playback point Playback Buffer Sequence number Packet arrival Packet generation Playback Network delay Time Buffer Example Distribution of Delays 90% 97% 98% Packets (%) 3 99% 2 1 50 100 Delay (milliseconds) 150 200 Components of Integrated Services architecture • Reservations (includes reservation protocol) • Admission control based on flow description and current load • Scheduling to follow through on reservation • Traffic shaping at edges to fit reservation • Some application adaptation Types of guarantees • • • • Absolute bound on delay and jitter Absolute bound on delay only Statistical bound on delay No quantitative delay bound but admission control and preferential treatment • None Internet service classes proposed by IETF • Guaranteed service – firm bounds on e2e delays and bandwidth • Controlled load – “a QoS closely approximating the QoS that same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded” • Best effort Taxonomy of applications Applications Real-Time Loss, delay tolerant adaptive Delay adaptive Non-adaptive Rate adaptive Elastic Intolerant Interactive Rate adaptive Asynchronous Non-adaptive Interactive-bulk Statistical multiplexing • Share output link among many sources • Strong law of large numbers: – Given large set of uncorrelated flows, total BW required nearly constant even if individual flows vary a lot – Intuition: if many flows, then each is small compared to aggregate and bursts come at different times – if correlated, bursts come at same time Self-similarity • Problem: self-similarity persists at all levels • Burstiness even for aggregates • Heavy-tailed distributions at all aggregations Utility curve shapes U Elastic BW U Delay-adaptive BW U Hard real-time BW Stay to the right and you are fine for all curves Overview of mechanisms • Flow specification (flowspec) – type of service we require • Admission control – can the network provide the requested service? • Resource reservation protocol – RSVP • Packet scheduling Flowspecs • Tspec: describes the flow’s traffic characteristics • Rspec: describes the service requested from the network Token bucket filter • Described by 2 parameters: – token rate r: rate of tokens placed in the bucket – bucket depth B: capacity of the bucket • Operation: – – – – tokens are placed in bucket at rate r if bucket fills, tokens are discarded sending a packet of size P uses P tokens if bucket has P tokens, packet sent at max rate, else must wait for tokens to accumulate Token bucket operation tokens overflow tokens tokens Packet Enough tokens packet goes through, tokens removed Packet Not enough tokens - wait for tokens to accumulate TB characteristics • On the long run, rate is limited to r • On the short run, a burst of size B can be sent • Amount of traffic entering at interval T is bounded by: – traffic = B + r*T • Information useful to admission algorithm Token bucket specs Flow A: r = 1 Mbps, B=1 byte BW 2 Flow B 1 Flow B: r = 1 Mbps, B=1MB Flow A 1 2 3 Time Admission control • When new flow, look at Rspec and Tspec and decide whether to admit or reject • Not policing Parekh bound on delay across net Di = (bucket size/weighted rate allocated) + [(nhops - 1) * MaxPacketLen / weighted rate allocation] + S m=1 to hopi (max packet length / outbound bw at hop) – 1st term: delay when running at full speed – 2nd term: packetization effects – 3rd term: added delay due to packet approx of FQ (goes away as data rate increases) Reservation protocol: RSVP Upper layer protocols and applications IP service interface IP ICMP IGMP RSVP Link layer service interface Link layer modules RSVP • Used on connectionless networks • Relies on soft state: reservations must be refreshed and do not have to be explicitly deleted • Aims to support multicast as effectively as unicast flows - mcast apps good candidates for real-time, and are heterogeneous • Receiver-oriented approach Role of RSVP • Rides on top of unicast/multicast routing protocols • Carries resource requests all the way through the network • At each hop consults admission control and sets up reservation. Informs requester if failure • RSVP only carries messages Changing reservation • Receiver-oriented approach and soft state make it easy to modify reservation • Modification sent with periodic refresh Basic message types • PATH message • RESV message • CONFIRMATION message – generated only upon request – unicast to receiver when RESV reaches node with established state • TEARDOWN message • ERROR message (if path or RESV fails) Making a reservation • Receivers make reservation • Before making a reservation, receiver must know: – type of traffic sender will send (Tspec) – path the sender’s packets will follow • Both can be accomplished by sending PATH messages PATH messages • PATH messages carry sender’s Tspec • Routers note the direction PATH messages arrived and set up reverse path to sender • Receivers send RESV messages that follow reverse path and setup reservations • If reservation cannot be made, user gets an error PATH and RESV messages Sender 1 PATH R Sender 2 PATH RESV (merged) RESV R receiver 1 R R RESV receiver 2 Soft State • Routing protocol makes routing changes, RSVP adjusts reservation state • In absence of route or membership changes, periodic PATH and RESV msgs refresh established reservation state • When change, new PATH msgs follow new path, new RESV msgs set reservation • Non-refreshed state times out automatically Router handling of RESV messages • If new request rejected, send error message • If admitted: – install packet filter into forwarding dbase – pass flow parameters to scheduler – activate packet policing if needed – forward RESV msg upstream Packet classifying and scheduling • Each arriving packet must be: – classified: associated with the application reservation • fields: source + destination address, protocol number, source + destination port – scheduled: managed in the queue so that it receives the requested service • implementation not specified in the service model, left up to the implementors RSVP and multicast • Reservations from multiple receivers for a single sender are merged together at branching points • Reservations for multiple senders may not be added up: – audio conference, not many talk at same time – only subset of speakers (filters) – mixers and translators RSVP deployment • • • • Authentication and access control Accounting and charging Policy control Future direction? – tightly coupled with the future direction of the Internet service model RSVP versus ATM (Q.2931) • RSVP – receiver generates reservation – soft state (refresh/timeout) – separate from route establishment – QoS can change dynamically – receiver heterogeneity • ATM – sender generates connection request – hard state (explicit delete) – concurrent with route establishment – QoS is static for life of connection – uniform QoS to all receivers ATM Service Categories • CBR – Constant Bit Rate – Continuous flow of data with tight bounds on delay and delay variation • rt-VBR – Real-Time Variable Bit Rate – Variable bandwidth with tight bounds on delay and delay variation • nrt-VBR – Non-Real-Time Variable Bit Rate – Variable bandwidth with tight bound on cell loss • UBR – Unspecified Bit Rate – No guarantees (i.e., best effort delivery) • ABR – Available Bit Rate 7 Traffic Management 6 5 4 3 2 0 Virtual Path Identifier Virtual Path Identifier Virtual Channel Identifier Virtual Channel Identifier Virtual Channel Identifier Payload Type Identifier Header Error Check • Problem: Providing quality of service 1 Generic Flow Control Payload (48 bytes) – How should ATM network resources be allocated to ensure good performance including preventing congestion, e.g., how many virtual channels should be assigned to a particular transmission link? • Solution: Traffic Management – Specify the traffic "contract" on each virtual channel/path – Route (including rejecting setup request) each virtual channel/path along a path with adequate resources (Admission Control) – Mark (via Cell Loss Priority bit) for loss all cells that violate the contract (Traffic Policing) CLP 7 6 5 4 2 1 0 Virtual Path Identifier Virtual Path Identifier Virtual Channel Identifier Generic Cell Rate Algorithm Virtual Channel Identifier Virtual Channel Identifier I for each cell arrival 3 Generic Flow Control Payload Type Identifier CLP Header Error Check Payload (48 bytes) • For a sequence of cell arrival times, {tk}, determines which cells conform to the traffic contract • A counter scheme based on two parameters denoted GCRA(I,L) L+I – Increment parameter: I • affects cell rate – Limit parameter: L One unit leak per unit of time • affects cell bursts • “Leaky bucket” – A cell that would cause the bucket to overflow is non-conforming 7 Smooth Traffic 6 5 4 Cell No Cell Virtual Channel Identifier Payload (48 bytes) Cell Cell 2 2 1 1 1 1 1 t+ t- t+ t- t+ Bucket fill just before and just after cell transmit time time Payload Type Identifier Header Error Check 2 t- 0 Virtual Path Identifier Virtual Channel Identifier 2 t+ 1 Virtual Channel Identifier 2 t- 2 Virtual Path Identifier GCRA(1.5, .5) Cell 3 Generic Flow Control t- t+ CLP 7 Bursty Traffic 6 Cell Cell No Cell No Cell 10 5 5 5 5 5 t- t+ Payload Type Identifier Payload (48 bytes) 10 t+ t- 1 0 Virtual Channel Identifier Header Error Check 10 t- 2 Virtual Path Identifier Virtual Channel Identifier 10 t+ 3 Virtual Channel Identifier 10 t- 4 Virtual Path Identifier GCRA(4.5, 7) Cell 5 Generic Flow Control t+ Bucket fill just before and just after cell transmit time t- t+ CLP 7 6 5 4 3 2 1 0 Generic Flow Control Virtual Path Identifier Virtual Path Identifier Virtual Channel Identifier Payload Type Identifier Virtual Channel Identifier Virtual Channel Identifier Payload Type Identifier CLP Header Error Check Payload (48 bytes) • Bit 3: Used to discriminate data cells from operation, administration, maintenance cells. • Bit 2: Used to indicate congestion in data cells (Bit 3 = 0) – Set by Switches – Source and Destination Behavior Defined for Available Bit Rate Flow Control VCC’s • Bit 1: Carried transparently end-to-end in data cells – Used by AAL5 C 7 ABR Feedback Forward RM* Cells 5 4 3 2 1 0 Virtual Path Identifier Virtual Path Identifier Virtual Channel Identifier Virtual Channel Identifier Virtual Channel Identifier Payload Type Identifier CLP Header Error Check Payload (48 bytes) + Source Rate & Congestion Indication 6 Generic Flow Control + Congestion Indication Rate Indication + + Destination + Backward RM* Cells • Source sets Actual Cell Rate based on rate & congestion feedback *- Resource Management B Actual Cell Rate Peak Cell Rate Minimum Cell Rate Network Congestion Example Source Cell Rate Profile Time C DiffServ • Analogy: – airline service, first class, coach, various restrictions on coach as a function of payment • Best-effort expected to make up bulk of traffic, but revenue from first class important to economic base (will pay for more plentiful bandwidth overall) • Not motivated by real-time! Motivated by economics and assurances Types of service • Premium service: (type P) – admitted based on peak rate – conservative, virtual wire services – unused premium goes to best effort (subsidy!) • Assured service: (type A) – based on expected capacity usage profiles – traffic unlikely to be dropped if user maintains profile. Out-of-profile traffic marked Differences with RSVP • No need for reservations: just mark packets • Packet marking can be done at administrative boundaries before injecting packets into network • Significant savings in signaling, much simpler overall Premium service • User sends within profile, network commits to delivery with requested profile • Simple forwarding: classify packet in one of two queues, use priority • Shaping at trust boundaries only, using token bucket • Signaling, admission control may get more elaborate, but still not end-to-end Premium traffic flow Company A Packets in premium flows have bit set Premium packet flow restricted to R bytes/sec internal router host first hop router ISP border router border router Unmarked packet flow 2-bit differentiated service • Precedence field encodes P & A type packets • P packets are queued at higher priority than ordinary best effort • A packets treated preferentially wrt dropping probability in the normal queue • Leaf and border routers have input and output tasks - other routers just output Leaf router input functionality Marker 1 Marker N Arriving packet Clear A&P bits Packet classifier Best effort Forwarding engine Markers: service class, rate, permissible burst size Marker function in routers • Leaf routers have traffic profiles - they classify packets based on packet header • If no profile present, pass as best effort • If profile is for A: – mark in-profile packets with A, forward others unmarked • If profile is for P: – delay out-of -profile packets to shape into profile Markers to implement two different services Drop on overflow Packet input Wait for token Set P bit Packet output No token Packet input Test if token token Set A bit Packet output Output forwarding • 2 queues: P packets on higher priority queue • Lower priority queue implements RED “In or Out” scheme (RIO) • At border routers profile meters test marked flows: – drop P packets out of profile – unmark A packets Router output interface for two-bit architecture P-bit set? yes High-priority Q Packets out no If A-bit set incr A_cnt Low-priority Q RIO queue management If A-bit set decr A_cnt Border router input interface Profile Meters A set Arriving packet Is packet marked? Token available? no Clear A-bit token Forwarding engine Not marked token P set Token available? no Drop packet Red with In or Out (RIO) • Precursor to Assured Forwarding (AF) PHB • Similar to RED, but with two separate probability curves • Has two classes, “In” and “Out” (of profile) • “Out” class has lower Minthresh, so packets are dropped from this class first • As avg queue length increases, “in” packets are dropped RIO drop probabilities P(drop) 1.0 MaxP Minout Minin Maxout Maxin AvgLen Today’s Homework • Peterson & Davie, Chap 4,6 -6.13 -6.32 -6.43 -6.44 -6.45 Download and browse RSVP & DiffServe RFC’s 78