Scheduling and queue management DigiComm II
Traditional queuing behaviour in routers • Data transfer: • datagrams: individual packets • no recognition of flows • connectionless: no signalling • Forwarding: • based on per-datagram, forwarding table look-ups • no examination of “type” of traffic – no priority traffic • Traffic patterns DigiComm II
Questions • How do we modify router scheduling behaviour to support QoS? • What are the alternatives to FCFS? • How do we deal with congestion? DigiComm II
Scheduling mechanisms DigiComm II
Scheduling [1] • Service request at server: • e.g. packet at router inputs • Service order: • which service request (packet) to service first? • Scheduler: • decides service order (based on policy/algorithm) • manages service (output) queues • Router (network packet handling server): • service: packet forwarding • scheduled resource: output queues • service requests: packets arriving on input lines DigiComm II
Scheduling [2] Simple router schematic forwarding / routing scheduler • Input lines: policy • no input buffering forwarding / routing • Packet classifier: tables • policy-based classification • Correct output queue: packet classifier(s) • forwarding/routing tables output buffer(s) • switching fabric switching • output buffer (queue) fabric • Scheduler: • which output queue serviced next DigiComm II
FCFS scheduling • Null packet classifier • Packets queued to outputs in order they arrive • No packet differentiation • No notion of flows of packets • Anytime a packet arrives, it is serviced as soon as possible: • FCFS is a work-conserving scheduler DigiComm II
Conservation law [1] • FCFS is work-conserving: • not idle if packets waiting • Reduce delay of one flow, N q C " $ = increase the delay of one n n n 1 = or more others $ = # µ n n n : mean link utlisation $ • We can not give all flows n q : mean delay due to scheduler a lower delay than they n C : constant [s] would get under FCFS : mean packet rate [p/s] # n : mean per packet service rate [s/p] µ ! n DigiComm II
Conservation law [2] Example • Change f1: • λ 1 : 15p/s • µ n : 0.1ms/p (fixed) • q 1 : 0.1s • Flow f1: • ρ 1 q 1 = 1.5 × 10 -7 s • λ 1 : 10p/s • For f2 this means: • q 1 : 0.1ms • decrease λ 2 ? • ρ 1 q 1 = 10 -7 s • decrease q 2 ? • Flow f2: • Note the trade-off for f2: • λ 2 : 10p/s • delay vs. throughput • q 2 : 0.1ms • Change service rate ( µ n ): • ρ 2 q 2 = 10 -7 s • C = 2 × 10 -7 s • change service priority DigiComm II
Non-work-conserving schedulers • Non-work conserving Less jitter disciplines: Makes downstream traffic • can be idle even if packets more predictable: waiting • output flow is controlled • allows “smoothing” of • less bursty traffic packet flows Less buffer space: • Do not serve packet as • router: output queues soon as it arrives: • end-system: de-jitter buffers • wait until packet is eligible Higher end-to-end delay for transmission Complex in practise • Eligibility: • may require time • fixed time per router, or synchronisation at routers • fixed time across network DigiComm II
Scheduling: requirements • Ease of implementation: • Performance bounds: • simple fast • per-flow bounds • high-speed networks • deterministic (guaranteed) • low complexity/state • statistical/probabilistic • implementation in hardware • data rate, delay, jitter, loss • Fairness and protection: • Admission control: • local fairness: max-min • (if required) • local fairness global • should be easy to fairness implement • protect any flow from the • should be efficient in use (mis)behaviour of any other DigiComm II
The max-min fair share criteria • Flows are allocated m min( x , M ) 1 n N = ! ! resource in order of n n n n 1 increasing demand " C m # " i • Flows get no more than M i 1 = = n N n 1 " + they need C : capacity of resource (maximum resource) • Flows which have not m : actual resource allocation to flow n n been allocated as they x : resource demand by flow n , x x x L ! ! n 1 2 N demand get an equal share M : resource available to flow n n of the available resource • Weighted max-min fair Example: share possible C = 10, four flow with demands of 2, 2.6, 4, 5 • If max-min fair actual resource allocations are 2, 2.6, 2.7, 2.7 provides protection DigiComm II
Scheduling: dimensions • Priority levels: • Degree of aggregation: • how many levels? • flow granularity • higher priority queues • per application flow? services first • per user? • can cause starvation lower • per end-system? priority queues • cost vs. control • Work-conserving or not: • Servicing within a queue: • must decide if delay/jitter • “FCFS” within queue? control required • check for other parameters? • is cost of implementation of • added processing overhead delay/jitter control in • queue management network acceptable? DigiComm II
Simple priority queuing • K queues: • 1 ≤ k ≤ K • queue k + 1 has greater priority than queue k • higher priority queues serviced first Very simple to implement Low processing overhead • Relative priority: • no deterministic performance bounds Fairness and protection: • not max-min fair: starvation of low priority queues DigiComm II
Generalised processor sharing (GPS) • Work-conserving • Provides max-min fair share ( n ) 1 n N % # # S ( i , , t ) 1 i N $ # # • Can provide weighted S ( i , , t ) ( i ) $ % max-min fair share " S ( j , , t ) ( j ) $ % • Not implementable: ( n ) : weight given to flow n % • used as a reference for S ( i , , t ) : service to flow i in interval [ôô,t $ comparing other schedulers flow i has a non empty queue ! • serves an infinitesimally small amount of data from flow i • Visits flows round-robin DigiComm II
GPS – relative and absolute fairness S ( i , , t ) S ( j , , t ) • Use fairness bound to % % RFB = " g ( i ) g ( j ) evaluate GPS emulations S ( i , , t ) G ( i , , t ) % % (GPS-like schedulers) AFB = " g ( i ) g ( i ) • Relative fairness bound: S ( i , , t ) : actual service for flow i in [ , t ] % % • fairness of scheduler with G ( i , , t ) : GPS service for flow i in [ , t ] % % respect to other flows it is g ( i ) min{ g ( i , 1 ), , g ( i , K )} L = servicing ( i , k ) r ( k ) $ g ( i , k ) = • Absolute fairness bound: N ( j , k ) # $ • fairness of scheduler j 1 = compared to GPS for the ( i , k ) : weight given to flow i at router k $ same flow r ( k ) : service rate of router k 1 i N flow number ! ! 1 k K router number ! ! DigiComm II
Weighted round-robin (WRR) • Simplest attempt at GPS • Service is fair over long timescales: • Queues visited round- • must have more than one robin in proportion to visit to each flow/queue weights assigned • short-lived flows? • Different mean packet • small weights? sizes: • large number of flows? • weight divided by mean packet size for each queue • Mean packets size unpredictable: • may cause unfairness DigiComm II
Deficit round-robin (DRR) • DRR does not need to • Queues not served during know mean packet size round build up “credits”: • only non-empty queues • Each queue has deficit counter (dc): initially zero • Quantum normally set to max expected packet size: • Scheduler attempts to • ensures one packet per serve one quantum of data round, per non-empty queue from a non-empty queue: • RFB: 3T/r (T = max pkt • packet at head served if service time, r = link rate) size ≤ quantum + dc dc quantum + dc – size • Works best for: • else dc += quantum • small packet size • small number of flows DigiComm II
Weighted Fair Queuing (WFQ) [1] • Based on GPS: • Round-number : • GPS emulation to produce • execution of round by bit- finish-numbers for packets by-bit round-robin server in queue • finish-number calculated • Simplification: GPS from round number emulation serves packets • If queue is empty: bit-by-bit round-robin • finish-number is: • Finish-number : number of bits in packet + • the time packet would have round-number completed service under • If queue non-empty: (bit-by-bit) GPS • finish-number is: • packets tagged with finish- highest current finish number number for queue + • smallest finish-number number of bits in packet across queues served first DigiComm II
Recommend
More recommend
