Scheduling and Policing 2007. Outline What is scheduling? Why we need it? What is scheduling? Why we need it? Requirements of a scheduling discipline.

Scheduling and Policing 2007

Outline What is scheduling? Why we need it? What is scheduling? Why we need it? Requirements of a scheduling discipline Requirements of a scheduling discipline Fundamental choices Fundamental choices Scheduling best effort connections Scheduling best effort connections Scheduling guaranteed-service connections Scheduling guaranteed-service connections Packet drop strategies Packet drop strategies Policing Policing

Scheduling Sharing always results in contention Sharing always results in contention A scheduling discipline resolves contention: who’s next? A scheduling discipline resolves contention: who’s next? Problem: given N packet streams contending for the same channel, how to schedule pkt transmissions? Problem: given N packet streams contending for the same channel, how to schedule pkt transmissions? Key to fairly sharing resources and providing performance guarantees - divide apple pie Key to fairly sharing resources and providing performance guarantees - divide apple pie

Components A scheduling discipline does two things: A scheduling discipline does two things:  decides service order  manages queue of service requests -- loss when Q is full Example: web server Example: web server  consider queries awaiting web server  scheduling discipline decides service order  and also if some query should be ignored

Where? Anywhere where contention may occur Anywhere where contention may occur At every layer of protocol stack At every layer of protocol stack Usually studied at network layer, at output queues of switches Usually studied at network layer, at output queues of switches

Why do we need one? Because future applications need it Because future applications need it We expect two types of future applications We expect two types of future applications  best-effort (adaptive, non-real time) elastic  e.g. email, some types of file transfer  guaranteed service (non-adaptive, real time)  e.g. packet voice, interactive video, stock quotes -- 64 kbps, 150msRTT

Why and where scheduling?

What can scheduling disciplines do? Give different users different qualities of service Give different users different qualities of service Example of passengers waiting to board a plane Example of passengers waiting to board a plane  early boarders spend less time waiting  bumped off passengers are ‘lost’! Scheduling disciplines can allocate Scheduling disciplines can allocate  bandwidth  delay  loss They also determine how fair the network is They also determine how fair the network is

The Conservation Law Traffic class/Connection i: (KL_Q_v2_117) Traffic class/Connection i: (KL_Q_v2_117) λ i x i ρ i =λ i x i q i -- mean waiting time λ i x i ρ i =λ i x i q i -- mean waiting time Example 9.2 155 Mbps ATM -- two virtual circuits A: 10 Mbps, 0.5 ms --> 0.1 ms B: 25 Mbps, 0.5 ms --> mean Q delay D = ? 10/155*0.5+25/155*0.5 = 10/155*0.1+25/155*D D =0.66 ms Example 9.2 155 Mbps ATM -- two virtual circuits A: 10 Mbps, 0.5 ms --> 0.1 ms B: 25 Mbps, 0.5 ms --> mean Q delay D = ? 10/155*0.5+25/155*0.5 = 10/155*0.1+25/155*D D =0.66 ms

Outline What is scheduling? Why we need it? What is scheduling? Why we need it? Requirements of a scheduling discipline Requirements of a scheduling discipline Fundamental choices Fundamental choices Scheduling best effort connections Scheduling best effort connections Scheduling guaranteed-service connections Scheduling guaranteed-service connections Packet drop strategies Packet drop strategies

Requirements easy to implement easy to implement fair (for best effort) fair (for best effort)  protected against abusive sources provides performance bounds (for guaranteed service) provides performance bounds (for guaranteed service) allows easy admission control decisions (for guaranteed service) allows easy admission control decisions (for guaranteed service)  to decide whether a new flow can be allowed

Requirement 1. Ease of implementation Scheduling discipline has to make a decision once every few ns ! 40 B-packet / 40 Gbps --> 8 ns Scheduling discipline has to make a decision once every few ns ! 40 B-packet / 40 Gbps --> 8 ns Should be implementable in a few instructions or hardware Should be implementable in a few instructions or hardware  for hardware: critical constraint is VLSI space Work per packet should scale less than linearly with number of active connections Work per packet should scale less than linearly with number of active connections  Scheduling overhead - independent of number of active connections

Requirement 2. Fairness Scheduling discipline allocates a resource Scheduling discipline allocates a resource An allocation is fair if it satisfies max-min fairness An allocation is fair if it satisfies max-min fairness  resource is equally shared  each connection gets no more than what it wants  the excess, if any, is equally shared The minimum of the flows should be as large as possible The minimum of the flows should be as large as possible AB C AB C Transfer half of excess Unsatisfied demand

Fairness (cont.) Definition: max-min fair allocates -- it maximizes the minimum share of a resource whose demand is not filly satisfied Definition: max-min fair allocates -- it maximizes the minimum share of a resource whose demand is not filly satisfied  Resources are allocated in order of increasing demand  No resource gets a resource share large than its demand  Sources with unsatisfied demands get an equally share K-ex 9.3 K-ex 9.3  resource capacity -- 10  4 connection demand -- 2, 2.6, 4, 5  allocate 2, 2.6, 2.7, 2.7  10/4=2.5,  2.5-2=0.5, 0.5/3=0.166,  2.5+0.166-2.6=0.066, 0.06/2=0.033

Fairness (cont.) Fairness is intuitively a good idea Fairness is intuitively a good idea But it also provides protection But it also provides protection  traffic hogs cannot overrun others  automatically builds firewalls around heavy users Fairness is a global objective, but scheduling is local Fairness is a global objective, but scheduling is local  flow is a global objective, switch is local  Each endpoint must restrict its flow to the smallest fair allocation along its path  Dynamics + delay => global fairness may never be achieved

Requirement 3. Performance bounds What is it? What is it?  A way to obtain a desired level of service Can be deterministic or statistical Can be deterministic or statistical Common parameters are Common parameters are  bandwidth  delay  delay-jitter  loss

Fundamental choices 1. Number of priority levels 2. Work-conserving vs. non-work-conserving non-work-conserving 3. Degree of aggregation 4. Service order within a level

Choices: 1. Priority Packet is served from a given priority level only if no packets exist at higher levels (multilevel priority with exhaustive service) Packet is served from a given priority level only if no packets exist at higher levels (multilevel priority with exhaustive service) Highest level gets lowest delay Highest level gets lowest delay Watch out for starvation! Watch out for starvation! Usually map priority levels to delay classes Usually map priority levels to delay classes Low bandwidth urgent messages RealtimeNon-realtime Priority

Choices: 2. Work conserving vs. non-work- conserving Work conserving discipline is never idle when packets await service Work conserving discipline is never idle when packets await service Why non-work conserving? -> less burst Why non-work conserving? -> less burst A - smooth A - burst A - smooth A - burst B -burst B - burst B -burst B - burst

Non-work-conserving disciplines (Regulators) Key conceptual idea: delay packet till eligible Key conceptual idea: delay packet till eligible Reduces delay-jitter => less burst, fewer buffers, less loss in network Reduces delay-jitter => less burst, fewer buffers, less loss in network How to choose eligibility time? How to choose eligibility time?  rate-jitter regulator  bounds maximum outgoing rate  delay-jitter regulator  compensates for variable delay at previous hop

Do we need non-work-conservation? Can remove delay-jitter at an endpoint instead Can remove delay-jitter at an endpoint instead  but also reduces size of switch buffers… Increases mean delay Increases mean delay  not a problem for playback applications Wastes bandwidth Wastes bandwidth  can serve best-effort packets instead Always punishes a misbehaving source Always punishes a misbehaving source  can’t have it both ways ? Bottom line: not too bad, implementation cost may be the biggest problem - calendar Q - K-p228 Bottom line: not too bad, implementation cost may be the biggest problem - calendar Q - K-p228

Outline What is scheduling What is scheduling Why we need it Why we need it Requirements of a scheduling discipline Requirements of a scheduling discipline Fundamental choices Fundamental choices Scheduling best effort connections Scheduling best effort connections Scheduling guaranteed-service connections Scheduling guaranteed-service connections Packet drop strategies Packet drop strategies

Scheduling best-effort connections Main requirement is fairness Main requirement is fairness Fairness Goals Fairness Goals  Allocate resources fairly  Isolate ill-behaved users  Router does not send explicit feedback to source  Still needs e2e congestion control  Still achieve statistical muxing  One flow can fill entire pipe if no contenders  Work conserving  scheduler never idles link if it has a packet

A Caveat: Still need e2e Congestion collapse can still happen if you have fair queueing (router-assisted sharing) Congestion collapse can still happen if you have fair queueing (router-assisted sharing) 10 Mbps 1.5 Mbps 128 Kbps TCP Non-cong. Ctl’d UDP Example from Floyd and Fall, 1999

Generalized Processor Sharing (GPS) Main requirement is fairness (max-min fair allocates) Main requirement is fairness (max-min fair allocates) Achievable using Generalized Processor Sharing (GPS) Achievable using Generalized Processor Sharing (GPS)  Visit each non-empty queue in turn  Serve infinitesimal from each  Why is this fair?  How can we give weights to connections?

More on GPS GPS is ideal and unimplementable! GPS is ideal and unimplementable!  we cannot serve infinitesimal, only packets No packet discipline can be as fair as GPS No packet discipline can be as fair as GPS  while a packet is being served, we are unfair to others Degree of unfairness can be bounded Degree of unfairness can be bounded  Define: work(I,a,b) = # bits transmitted for connection I in time [a,b]  Absolute fairness bound for discipline S  Max (work_GPS(I,a,b) - work_S(I, a,b))  Relative fairness bound for discipline S  Max (work_S(I,a,b) - work_S(J,a,b))

Weighted Fair Queueing (WFQ) GPS is fairest discipline GPS is fairest discipline Find the finish time of a packet, had we been doing GPS Find the finish time of a packet, had we been doing GPS Then serve packets in order of their finish times Then serve packets in order of their finish times Deals better with variable size packets and weights Deals better with variable size packets and weights Weighted round robin Weighted round robin  Unfair if packets are of different length or weights are not equal

WFQ: first cut Suppose, in each round, the server served one bit from each active connection Suppose, in each round, the server served one bit from each active connection Round number is the number of rounds already completed. It can be fractional Round number is the number of rounds already completed. It can be fractional If a packet of length p arrives to an empty queue when the round number is R, it will complete service when the round number If a packet of length p arrives to an empty queue when the round number is R, it will complete service when the round number is R + p => finish number is R + p is R + p => finish number is R + p  independent of the number of other connections! If a packet arrives to a non-empty queue, and the previous packet has a finish number of f, then the packet’s finish number is f + p If a packet arrives to a non-empty queue, and the previous packet has a finish number of f, then the packet’s finish number is f + p Serve packets in order of finish numbers (≠ finish time) Serve packets in order of finish numbers (≠ finish time)

WFQ continued To sum up, assuming we know the current round number R To sum up, assuming we know the current round number R Finish number of packet of length p Finish number of packet of length p  if arriving to active connection = previous finish number f + p  if arriving to an inactive connection = R + p (How should we deal with weights?) (How should we deal with weights?) To implement, we need to know two things: To implement, we need to know two things:  is connection active?  if not, what is the current round number? Answer to both questions depends on computing the current round number (why?) Answer to both questions depends on computing the current round number (why?)

WFQ: computing the round number Naively: round number = number of rounds of service completed so far Naively: round number = number of rounds of service completed so far  what if a server has not served all connections in a round?  what if new conversations join in halfway through a round? Redefine round number as a real-valued variable that increases at a rate inversely proportional to the number of currently active connections Redefine round number as a real-valued variable that increases at a rate inversely proportional to the number of currently active connections  this takes care of both problems (why?) With this change, WFQ emulates GPS instead of bit-by-bit RR With this change, WFQ emulates GPS instead of bit-by-bit RR

WFQ: computing the round number + K - Ex 9.10 K - Ex 9.10 arrival: A: (size=10,t=0) (20,40), B: (20,0), C: (20,0) service rate: 1 unit/s, equally weighted arrival: A: (size=10,t=0) (20,40), B: (20,0), C: (20,0) service rate: 1 unit/s, equally weighted

Problem: iterated deletion Ex: Keshav p242 Ex: Keshav p242 t= act connections rate round num t= act connections rate round num 0 5 1/5 0 0 5 1/5 0 5 1 --> 1.05 --> 1.05+ 5 1 --> 1.05 --> 1.05+ 4 a depart -> 4 ---> 1/4 --------------^ 4 a depart -> 4 ---> 1/4 --------------^,-------------------------------’,-------------------------------’ 4.9 b depart -> 3 ---> 1/3 --------------------------^ 4.9 b depart -> 3 ---> 1/3 --------------------------^ A sever recomputes round number on each packet arrival/dept A sever recomputes round number on each packet arrival/dept Need improve WFQ Need improve WFQ Round number # active conversations - at arrival/departure

Problem: iterated deletion (cont) Trick Trick  use previous count to compute round number  if this makes some conversation inactive, recompute  repeat until no conversations become inactive Complex computation at arrival/departure Complex computation at arrival/departure  problem in high speed networks  overcoming iterated deletion problem,  e.g. Self-clocked fair queuing (SCFQ) Round number # active conversations - at arrival/departure

Evaluation Pros Pros  deals better with variable size packets and weights  like GPS, it provides protection  can obtain worst-case end-to-end delay bound  gives users incentive to use intelligent flow control (& provides rate information implicitly) Cons Cons  needs per-connection state  iterated deletion is complicated  requires a priority queue Variants of WFQ - implementing easily e.g. Self-clocked fair queuing (SCFQ), start-time fair queuing Variants of WFQ - implementing easily e.g. Self-clocked fair queuing (SCFQ), start-time fair queuing Since 1996, WFQ in Cisco, FORE,.. Since 1996, WFQ in Cisco, FORE,..

What does “fairness” divide between? At what granularity? At what granularity?  Flows, connections, domains? What if users have different RTTs/links/etc. What if users have different RTTs/links/etc.  Should it share a link fairly or be TCP fair? Basically a tough question to answer – typically design mechanisms instead of policy Basically a tough question to answer – typically design mechanisms instead of policy  User = arbitrary granularity  Paper has a nice argument for (src, dst) pairs

Scheduling guaranteed-service connections With best-effort connections, goal is fairness With best-effort connections, goal is fairness With guaranteed-service connections With guaranteed-service connections  what performance guarantees are achievable?  how easy is admission control? We now study some scheduling disciplines that provide performance guarantees We now study some scheduling disciplines that provide performance guarantees

WFQ WFQ also provides performance guarantees WFQ also provides performance guarantees Bandwidth bound Bandwidth bound  ratio of weights * link capacity  e.g. connections with weights 1, 2, 7; link capacity 10  connections get at least 1, 2, 7 units of b/w each End-to-end delay bound End-to-end delay bound  assumes that the connection doesn’t send ‘too much’ more  precisely, connection should be leaky- bucket regulated  Parekh-Gallager theorem

Parekh-Gallager theorem Let it be leaky-bucket regulated such that # bits sent in time [t 1, t 2 ] <= ρ(t 2 - t 1 ) + σ Let it be leaky-bucket regulated such that # bits sent in time [t 1, t 2 ] <= ρ(t 2 - t 1 ) + σ Let a connection be allocated weights at each WFQ scheduler along its path, so that the least bandwidth it is allocated is g -- g<g(k) Let a connection be allocated weights at each WFQ scheduler along its path, so that the least bandwidth it is allocated is g -- g<g(k)  g(k) – assigned service rate Let the connection pass through K schedulers, where the kth scheduler has a link rate r(k) Let the connection pass through K schedulers, where the kth scheduler has a link rate r(k) Let largest packet allowed in the network be P Let largest packet allowed in the network be P

Significance Theorem shows that WFQ can provide end- to-end delay bounds Theorem shows that WFQ can provide end- to-end delay bounds So WFQ provides both fairness and performance guarantees So WFQ provides both fairness and performance guarantees Bound holds regardless of cross traffic behavior Bound holds regardless of cross traffic behavior Can be generalized for networks where schedulers are variants of WFQ, and the link service rate changes over time Can be generalized for networks where schedulers are variants of WFQ, and the link service rate changes over time

Problems WFQ couples delay and bandwidth allocations WFQ couples delay and bandwidth allocations  low delay requires allocating more bandwidth  wastes bandwidth for low-bandwidth low- delay sources  g can be very large, in some cases 80 times the peak rate! Sources must be leaky-bucket regulated Sources must be leaky-bucket regulated  but choosing leaky-bucket parameters is problematic

Delay- EDD (Earliest Due Date) EDD: packet with earliest deadline selected EDD: packet with earliest deadline selected Delay-EDD prescribes how to assign deadlines to packets Delay-EDD prescribes how to assign deadlines to packets  Deadline = expected arrival time + delay bound  If a source sends faster than contract, delay bound will not apply A source is required to send slower than its peak rate A source is required to send slower than its peak rate  Bandwidth at scheduler reserved at peak rate  Each packet gets a hard delay bound Delay bound is independent of bandwidth requirement Delay bound is independent of bandwidth requirement  but reservation is at a connection’s peak rate Implementation requires per-connection state and a priority queue Implementation requires per-connection state and a priority queue

Rate-controlled scheduling A class of disciplines A class of disciplines  two components: regulator and scheduler  incoming packets are placed in regulator  where they wait to become eligible  then they are put in the scheduler Regulator shapes the traffic, scheduler provides performance guarantees Regulator shapes the traffic, scheduler provides performance guarantees

Examples Recall Non-work-conserving disciplines K-9.3.2 Recall Non-work-conserving disciplines K-9.3.2  rate-jitter regulator  bounds maximum outgoing rate  delay-jitter regulator  compensates for variable delay at previous hop Rate-jitter regulator + FIFO Rate-jitter regulator + FIFO  similar to Delay-EDD (what is the difference?) Rate-jitter regulator + multi-priority FIFO (RCSP-rate controlled static priority) K-ex-9.12 Rate-jitter regulator + multi-priority FIFO (RCSP-rate controlled static priority) K-ex-9.12  gives both bandwidth and delay guarantees Delay-jitter regulator + EDD (Jitter-EDD) Delay-jitter regulator + EDD (Jitter-EDD)  gives bandwidth, delay, and delay-jitter bounds

Analysis First regulator on path monitors and regulates traffic => bandwidth bound First regulator on path monitors and regulates traffic => bandwidth bound End-to-end delay bound End-to-end delay bound  delay-jitter regulator  reconstructs traffic => end-to-end delay is fixed (= worst-case delay at each hop)  rate-jitter regulator  partially reconstructs traffic  can show that end-to-end delay bound is smaller than (sum of delay bound at each hop + delay at first hop)

Decoupling K-ex-9.12 Can give a low-bandwidth connection a low delay without overbooking Can give a low-bandwidth connection a low delay without overbooking E.g consider connection A with rate 64 Kbps (highest- pri) and B with rate 1.5 Mbps (lower-pri) sent to a router with rate-jitter regulation and multipriority FCFS scheduling E.g consider connection A with rate 64 Kbps (highest- pri) and B with rate 1.5 Mbps (lower-pri) sent to a router with rate-jitter regulation and multipriority FCFS scheduling  A: After sending a packet of length l, next packet is eligible at time (now + l/64 Kbps)  If placed A at highest-priority queue, all packets (A) get low delay Decouple delay and bandwidth bounds, unlike WFQ Decouple delay and bandwidth bounds, unlike WFQ

Evaluation Pros Pros  flexibility: ability to emulate other disciplines  (diff- regulator + diff-scheduler)  can decouple bandwidth and delay assignments  end-to-end delay bounds are easily computed  do not require complicated schedulers to guarantee protection  can provide delay-jitter bounds Cons Cons  require an additional regulator at each output port  delay-jitter bounds at the expense of increasing mean delay  delay-jitter regulation is expensive (clock synch, timestamps)

Summary Two sorts of applications: best effort and guaranteed service Two sorts of applications: best effort and guaranteed service Best effort connections require fair service Best effort connections require fair service  provided by GPS, which is unimplementable  emulated by WFQ and its cheaper variants Guaranteed service connections require performance guarantees Guaranteed service connections require performance guarantees  provided by WFQ, but this is expensive (low delay -> large b/w)  may be better to use rate-controlled schedulers K-p253 Table K-p253 Table

Packet dropping Packets that cannot be served immediately are buffered Packets that cannot be served immediately are buffered Full buffers => packet drop strategy Full buffers => packet drop strategy Packet losses happen almost always from best-effort connections (why?) Packet losses happen almost always from best-effort connections (why?) Shouldn’t drop packets unless imperative Shouldn’t drop packets unless imperative  packet drop wastes resources (why?)

Classification of drop strategies 1. Degree of aggregation 2. Drop priorities 3. Early or late 4. Drop position

1.Degree of aggregation (classify packets ) Degree of discrimination in selecting a packet to drop Degree of discrimination in selecting a packet to drop  E.g. in vanilla FIFO, all packets are in the same class  Instead, can classify packets and drop packets selectively The finer the classification the better the protection The finer the classification the better the protection Max-min fair allocation of buffers to classes Max-min fair allocation of buffers to classes  share buffer  drop packet from class with the longest queue (why?)

2. Drop priorities Drop lower-priority packets first e.g. divide video stream Drop lower-priority packets first e.g. divide video stream How to choose? How to choose?  endpoint marks packets  regulator marks packets  congestion loss priority (CLP-ATM) bit in packet header

3. Early vs. late drop: RED RED (Random early detection) makes three improvements RED (Random early detection) makes three improvements  Metric is moving average of queue lengths  small bursts pass through unharmed  only affects sustained overloads  Packet drop probability is a linear function of mean queue length  prevents severe reaction to mild overload  Can mark packets instead of dropping them  allows sources to detect network state without losses

Weighted average queue length AvgLen = (1-Weight)AvgLen + (Weight)SampleLen AvgLen = (1-Weight)AvgLen + (Weight)SampleLen Filter out short-term changes in queue length Filter out short-term changes in queue length Queue length Instantaneous Average T ime

Drop proba bility function queue drop with P drop queue drop with P drop packet packet packet packet packet packet P(drop) 1.0 MaxP MinThresh MaxThresh AvgLen

RED benefits RED improves performance of a network of cooperating TCP sources RED improves performance of a network of cooperating TCP sources  No bias against bursty sources - good for TCP new open  Controls queue length regardless of endpoint cooperation RED only works if senders obey packet loss as congestion signal and back off RED only works if senders obey packet loss as congestion signal and back off RED improves fairness RED improves fairness  random

4. Drop position Can drop a packet from head, tail, or random position in the queue Can drop a packet from head, tail, or random position in the queue Tail Tail  easy  default approach Head Head  harder to implement  lets source detect loss earlier

Outline What is scheduling? Why we need it? What is scheduling? Why we need it? Requirements of a scheduling discipline Requirements of a scheduling discipline Fundamental choices Fundamental choices Scheduling best effort connections Scheduling best effort connections Scheduling guaranteed-service connections Scheduling guaranteed-service connections Packet drop strategies Packet drop strategies Core-Stateless Fair Queuing Core-Stateless Fair Queuing Policing (Regulating, Shaping ) Policing (Regulating, Shaping )

Fair Queuing Tradeoffs FQ can control congestion by monitoring flows FQ can control congestion by monitoring flows  Non-adaptive flows can still be a problem – why? Complex state Complex state  Must keep queue per flow  Hard in routers with many flows (e.g., backbone routers)  Flow aggregation is a possibility (e.g. do fairness per domain) Complex computation Complex computation  Classification into flows may be hard  Must keep queues sorted by finish times  dR/dt changes whenever the flow count changes

Core-Stateless Fair Queuing Key problem with FQ is core routers Key problem with FQ is core routers  core – an Internet AS backbone  Must maintain state for many (50-100k!) flows  Must update state at Gbps line speeds CSFQ (Core-Stateless FQ) objectives CSFQ (Core-Stateless FQ) objectives  Edge routers should do complex tasks since they have fewer flows (1000s)  Core routers can do simple tasks  No per-flow state/processing  this means that core routers can only decide on dropping packets not on order of processing  Can only provide max-min bandwidth fairness not delay allocation

Core-Stateless Fair Queuing Edge routers keep state about flows and do computation when packet arrives Edge routers keep state about flows and do computation when packet arrives DPS (Dynamic Packet State) DPS (Dynamic Packet State)  Edge routers label packets with the result of state lookup and computation  Note: Generalizes beyond CSFQ! Core routers use DPS and local measurements to control processing of packets Core routers use DPS and local measurements to control processing of packets

Key ideas DPS (Dynamic Packet State) DPS (Dynamic Packet State)  Edges estimate arrival rate for each flow (per-flow state) Core routers use Core routers use  Estimated arrival rates from edge  Internal measure of fair-share  To generate a drop probability. Labels changed on outbound flow with new post-drop arrival rate. Estimation for fair-share value converges rapidly Estimation for fair-share value converges rapidly

Edge Router Behavior Monitor each flow i to measure its arrival rate (R i ) Monitor each flow i to measure its arrival rate (R i )  EWMA of rate  t_i^k, l_i^k = arrival time, length of kth packet in flow i  Non-constant EWMA constant  T_i^k = interarrival (time since last pkt) (t_i^k – t_{i-1}^k)  Constant: e -T/K where T, K = constant  Ri new = (1 – const)* length/interarrival + const*(Ri old)  Helps adapt to different packet sizes and arrival patterns Intuition: Trusts the “old” values less as the time interval increases (negative T)Intuition: Trusts the “old” values less as the time interval increases (negative T) Rate is attached to each packet Rate is attached to each packet

Core Router Behavior Drop probability for packet = max (1-  /r, 0) Drop probability for packet = max (1-  /r, 0) Track aggregate input A Track aggregate input A Track accepted rate F(  ) Track accepted rate F(  ) Estimate fair share rate  Estimate fair share rate   Solve F(  ) = C; but this is hard:  Note: Increasing  does not increase load (F) by N * Δ  (why?)  F(  ) =  i min(r i,  )  what does this look like?  max-min fairness: allallocations converge to some value  such that all offered loads r i  are given a rate equal to 

F vs. Alpha New alpha C [linked capacity] r1r2r3old alpha alpha F

Estimating Fair Share Need F(  ) = capacity = C Need F(  ) = capacity = C  Can’t keep map of F(  ) values  would require per flow state  If we’re overutilized:  Since F(  ) is concave, piecewise-linear  F(0) = 0 and F(  ) = current accepted rate = F c  F(  ) = F c /   F(  new ) = C   new =  old * C/F c  If underutilized:   = max_i (ri) (No drops at all) What if a mistake was made? What if a mistake was made?  Forced into dropping packets due to buffer capacity  When queue overflows  is decreased slightly  Note that this is an increase/decrease rule in disguise.  Note that this is an increase/decrease rule in disguise.

Other Issues Punishing fire-hoses – why? Punishing fire-hoses – why?  Easy to keep track of in a FQ scheme What are the real edges in such a scheme? What are the real edges in such a scheme?  Must trust edges to mark traffic accurately  Could do some statistical sampling to see if edge was marking accurately

Outline What is scheduling? Why we need it? What is scheduling? Why we need it? Requirements of a scheduling discipline Requirements of a scheduling discipline Fundamental choices Fundamental choices Scheduling best effort connections Scheduling best effort connections Scheduling guaranteed-service connections Scheduling guaranteed-service connections Packet drop strategies Packet drop strategies Core-Stateless Fair Queuing Core-Stateless Fair Queuing Policing (Regulating, Shaping ) Policing (Regulating, Shaping )

Policing Mechanisms Goal: limit traffic to not exceed declared parameters parameters Three common-used criteria: (Long term) Average Rate: how many pkts can be sent per unit time (in the long run) (Long term) Average Rate: how many pkts can be sent per unit time (in the long run)  crucial question: what is the interval length: 100 packets per sec or 6000 packets per min have same average! Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 ppm peak rate Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 ppm peak rate (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle) (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle)

Leaky bucket

Token Bucket Token Bucket: limit input to specified Burst Size and Average Rate. bucket can hold bucket can hold b tokens b tokens tokens generated tokens generated at rate r token/sec at rate r token/sec unless bucket full unless bucket full over interval of length t: number of packets admitted less than or equal to (r t + b). over interval of length t: number of packets admitted less than or equal to (r t + b).  a linear function of time  Linear Bounded Arrival Process (LBAP)

Choosing Token Bucket parameters Tradeoff between r and b Tradeoff between r and b Minimal descriptor Minimal descriptor  doesn’t simultaneously have smaller r and b  presumably costs less How to choose minimal descriptor? How to choose minimal descriptor? Three way tradeoff Three way tradeoff  loss rate  choice of b (data bucket size)  choice of r

Choosing minimal parameters Keeping loss rate the same Keeping loss rate the same  if b is more, r is less (smoothing)  for each r we have least b Choose knee of curve Choose knee of curve

Policing Mechanisms (more) token bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., QoS guarantee! token bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., QoS guarantee! WFQ token rate, r bucket size, b per-flow rate, R D = b/R max arriving traffic

Leaky bucket Popular in practice and in academia Popular in practice and in academia  sort of representative  verifiable  sort of preservable  sort of usable Problems with multiple time scale traffic Problems with multiple time scale traffic  large burst messes up things Fig. 5-25 token bucket Fig. 5-25 token bucket  r T + b = MT  (c) 2T + 250 = 25T  T = 11

Scheduling and Policing 2007. Outline What is scheduling? Why we need it? What is scheduling? Why we need it? Requirements of a scheduling discipline.

Similar presentations

Presentation on theme: "Scheduling and Policing 2007. Outline What is scheduling? Why we need it? What is scheduling? Why we need it? Requirements of a scheduling discipline."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Scheduling and Policing 2007. Outline What is scheduling? Why we need it? What is scheduling? Why we need it? Requirements of a scheduling discipline.

Similar presentations

Presentation on theme: "Scheduling and Policing 2007. Outline What is scheduling? Why we need it? What is scheduling? Why we need it? Requirements of a scheduling discipline."— Presentation transcript:

Similar presentations

About project

Feedback