Scheduling and queue management. DigiComm II

Transcription

1 Schedulng and queue management

2 Tradtonal queung behavour n routers Data transfer: datagrams: ndvdual packets no recognton of flows connectonless: no sgnallng Forwardng: based on per-datagram forwardng table look-ups no examnaton of type of traffc no prorty traffc Traffc patterns

3 Questons How do we modfy router schedulng behavour to support QoS? What are the alternatves to FCFS? How do we deal wth congeston?

4 Schedulng mechansms

5 Schedulng [1] Servce request at server: e.g. packet at router nputs Servce order: whch servce request packet) to servce frst? Scheduler: decdes servce order based on polcy/algorthm) manages servce output) queues Router network packet handlng server): servce: packet forwardng scheduled resource: output queues servce requests: packets arrvng on nput lnes

6 Schedulng [2] Smple router schematc Input lnes: no nput bufferng Packet classfer: forwardng / routng polcy forwardng / routng tables scheduler polcy-based classfcaton Correct output queue: forwardng/routng tables swtchng fabrc output buffer queue) Scheduler: whch output queue servced next packet classfers) swtchng fabrc output buffers)

7 FCFS schedulng Null packet classfer Packets queued to outputs n order they arrve Do packet dfferentaton No noton of flows of packets Anytme a packet arrves t s servced as soon as possble: FCFS s a work-conservng scheduler

8 Conservaton law [1] FCFS s work-conservng: not dle f packets watng Reduce delay of one flow ncrease the delay of one or more others We can not gve all flows a lower delay than they would get under FCFS n= 1 = C ρ : mean lnk utlsaton q N n n n : mean delay due to scheduler C : constant [s] λ : mean packet rate[p/s] n µ : mean per packet servce rate[s/p] n ρ q n n ρ = λ µ n n

9 Conservaton law [2] Example µ n : 0.1ms/p fxed) Flow f1: λ 1 : 10p/s q 1 : 0.1ms ρ 1 q 1 = 10-7 s Flow f2: λ 2 : 10p/s q 2 : 0.1ms ρ 2 q 2 = 10-7 s C = s Change f1: λ 1 : 15p/s q 2 : 0.1s ρ 1 q 1 = s For f2 ths means: decrease λ 2? decrease q 2? Note the trade-off for f2: delay vs. throughput Change servce rate µ n ): change servce prorty

10 Non-work-conservng schedulers Non-work conservng dscplnes: can be dle even f packets watng allows smoothng of packet flows Do not serve packet as soon as t arrves: what untl packet s elgble for transmsson Elgblty: fxed tme per router or fxed tme across network Less jtter Makes downstream traffc more predctable: output flow s controlled less bursty traffc Less buffer space: router: output queues end-system: de-jtter buffers Hgher end-to-end delay Complex n practse may requre tme synchronsaton at routers

11 Schedulng: requrements Ease of mplementaton: smple fast hgh-speed networks low complexty/state mplementaton n hardware Farness and protecton: local farness: max-mn local farness global farness protect any flow from the ms)behavour of any other Performance bounds: per-flow bounds determnstc guaranteed) statstcal/probablstc data rate delay jtter loss Admsson control: f requred) should be easy to mplement should be effcent n use

12 The max-mn far share crtera Flows are allocated resource n order of ncreasng demand Flows get no more than they need Flows whch have not been allocated as they demand get an equal share of the avalable resource Weghted max-mn far share possble If max-mn far provdes protecton m C m 1 M n = N n + 1 C : capacty of resource maxmum resource) m x n M n n = mn x M 1 n N : actual resource allocaton to flow n : resource demand by flow n x n n n 1 = n ) : resource avalable to flow n Example: C = 10 four flow wth demands of actual resource allocatons are x 2 x N

13 Schedulng: dmensons Prorty levels: how many levels? hgher prorty queues servces frst can cause starvaton lower prorty queues Work-conservng or not: must decde f delay/jtter control requred s cost of mplementaton of delay/jtter control n network acceptable? Degree of aggregaton: flow granularty per applcaton flow? per user? per end-system? cost vs. control Servcng wthn a queue: FCFS wthn queue? check for other parameters? added processng overhead queue management

14 Smple prorty queung K queues: 1 k K queue k + 1 has greater prorty than queue k hgher prorty queues servced frst Very smple to mplement Low processng overhead Relatve prorty: no determnstc performance bounds Farness and protecton: not max-mn far: starvaton of low prorty queues

15 Generalsed processor sharng GPS) Work-conservng Provdes max-mn far share Can provde weghted max-mn far share Not mplementable: used as a reference for comparng other schedulers serves an nfntesmally small amount of data from flow Vsts flows round-robn φ n) 1 n N S τ t) 1 N S τ t) φ ) S j τ t) φ j) φ n) : weght gven to flow n S τ t) :servce to flow n nterval [ t flow has a non empty queue

16 GPS relatve and absolute farness Use farness bound to evaluate GPS emulatons GPS-lke schedulers) Relatve farness bound: farness of scheduler wth respect to other flows t s servcng Absolute farness bound: farness of scheduler compared to GPS for the same flow router number 1 flow number 1 router ) :servce rate of at router weght gven to flow ) : ) ) ) ) )} 1) mn{ ) ] n [ ) : GPS servce for flow ] n [ ) : actual servce for flow ) ) ) ) ) ) ) ) 1 K k N k k r k k k j k r k k g K g g g t t G t t S g t G g t S AFB j g t j S g t S RFB N j = = = = = φ φ φ τ τ τ τ τ τ τ τ

17 Weghted round-robn WRR) Smplest attempt at GPS Queues vsted roundrobn n proporton to weghts assgned Dfferent means packet szes: weght dvded by mean packet sze for each queue Mean packets sze unpredctable: may cause unfarness Servce s far over long tmescales: must have more than one vst to each flow/queue short-lved flows? small weghts? large number of flows?

18 Defct round-robn DRR) DRR does not need to know mean packet sze Each queue has defct counter dc): ntally zero Scheduler attempts to serve one quantum of data from a non-empty queue: packet at head served f sze quantum + dc dc quantum + dc sze else dc += quantum Queues not served durng round buld up credts : only non-empty queues Quantum normally set to max expected packet sze: ensures one packet per round per non-empty queue RFB: 3T/r T = max pkt servce tme r = lnk rate) Works best for: small packet sze small number of flows

19 Weghted Far Queung WFQ) [1] Based on GPS: GPS emulaton to produce fnsh-numbers for packets n queue Smplfcaton: GPS emulaton serves packets bt-by-bt round-robn Fnsh-number: the tme packet would have completed servce under bt-by-bt) GPS packets tagged wth fnshnumber smallest fnsh-number across queues served frst Round-number: executon of round by btby-bt round-robn server fnsh-number calculated from round number If queue s empty: fnsh-number s: number of bts n packet + round-number If queue non-empty: fnsh-number s: hghest current fnsh number for queue + number of bts n packet

20 Weghted Far Queung WFQ) [2] F k t) = max{ F k 1 t) R t)} + P k t) F k t) : fnsh - number for packet k P k t) : sze of on flow arrvng at tme t packet k on flow arrvng at tme t R t) : round - number at tme t Fφ k t) = max{ Fφ k 1 t) R t)} + φ ) : weght gven to flow P k t) φ ) Rate of change of Rt) depends on number of actve flows and ther weghts) As Rt) changes so packets wll be served at dfferent rates Flow completes empty queue): one less flow n round so R ncreases more quckly so more flows complete R ncreases more quckly etc. terated deleton problem WFQ needs to evaluate R each tme packet arrves or leaves: processng overhead

21 Weghted Far Queung WFQ) [3] Buffer drop polcy: packet arrves at full queue drop packets already n queued n order of decreasng fnshnumber Can be used for: best-effort queung provdng guaranteed data rate and determnstc end-to-end delay WFQ used n real world Alternatves also avalable: self-clocked far-queung SCFQ) worst-case far weghted far queung WF 2 Q)

22 Class-Based Queung Herarchcal lnk sharng: lnk capacty s shared class-based allocaton polcy-based class selecton Class herarchy: assgn capacty/prorty to each node node can borrow any spare capacty from parent fne-graned flows possble Note: ths s a queung mechansm: requres use of a scheduler app1 1% RT X appn NRT 100% root lnk) 40% 30% 30% 30% 10% Y 25% RT real-tme NRT non-real-tme RT Z 15% NRT

23 Queue management and congeston control

24 Queue management [1] Schedulng: whch output queue to vst whch packet to transmt from output queue Queue management: ensurng buffers are avalable: memory management organsng packets wthn queue packet droppng when queue s full congeston control

25 Queue management [2] Congeston: msbehavng sources source synchronsaton routng nstablty network falure causng re-routng congeston could hurt many flows: aggregaton Drop packets: drop new packets untl queue clears? admt new packets drop exstng packets n queue?

26 Packet droppng polces Drop-from-tal: easy to mplement delayed packets at wthn queue may expre Drop-from-head: old packets purged frst good for real tme better for TCP Random drop: far f all sources behavng msbehavng sources more heavly penalsed Flush queue: drop all packets n queue smple flows should back-off neffcent Intellgent drop: based on level 4 nformaton may need a lot of state nformaton should be farer

27 End system reacton to packet drops Non-real-tme TCP: packet drop congeston slow down transmsson slow start congeston avodance network s happy! Real-tme UDP: packet drop fll-n at recever?? applcaton-level congeston control requred flow data rate adaptaton not be suted to audo/vdeo? real-tme flows may not adapt hurts adaptve flows Queue management could protect adaptve flows: smart queue management requred

28 RED [1] Random Early Detecton: spot congeston before t happens drop packet source slows down prevents real congeston Whch packets to drop? montor flows pre-emptve congeston sgnal cost n state and processng overhead vs. overall performance of the network

29 RED [2] Probablty of packet drop queue length Queue length value exponental average: smooths reacton to small bursts punshes sustaned heavy traffc Packets can be dropped or marked as offendng : RED-aware routers more lkely to drop offendng packets Source must be adaptve: OK for TCP real-tme traffc UDP?

30 TCP-lke adaptaton for real-tme flows Mechansms lke RED requre adaptve sources How to ndcate congeston? packet drop OK for TCP packet drop hurts real-tme flows use ECN? Adaptaton mechansms: layered audo/vdeo codecs TCP s uncast: real-tme can be multcast

31 Schedulng and queue management: Dscusson Farness and protecton: queue overflow congeston feedback from router: packet drop? Scalablty: granularty of flow speed of operaton Flow adaptaton: non-real tme: TCP real-tme? Aggregaton: granularty of control granularty of servce amount of router state lack of protecton Sgnallng: set-up of router state nform router about a flow explct congeston notfcaton?

32 Summary Schedulng mechansms work-conservng vs. non-work-conservng Schedulng requrements Schedulng dmensons Queue management Congeston control