1 / 71

Scheduling and Policing 2007

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

gefen
Download Presentation

Scheduling and Policing 2007

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Scheduling and Policing 2007

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

  3. Scheduling • Sharing always results in contention • A scheduling discipline resolves contention: who’s next? • 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

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

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

  6. Why do we need one? • Because future applications need it • 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

  7. Why and where scheduling?

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

  9. The Conservation Law • Traffic class/Connection i: (KL_Q_v2_117) • λi xiρi =λi xi qi -- 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

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

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

  12. Requirement 1. Ease of implementation • 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 • for hardware: critical constraint is VLSI space • Work per packet should scale less than linearly with number of active connections • Scheduling overhead - independent of number of active connections

  13. Requirement 2. Fairness • Scheduling discipline allocates a resource • An allocation is fair if it satisfiesmax-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 Transfer half of excess Unsatisfied demand A B A B C C

  14. Fairness (cont.) • 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 • 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

  15. Fairness (cont.) • Fairness is intuitively a good idea • 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 • 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

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

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

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

  19. Choices: 1. Priority • 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 • Watch out for starvation! • Usually map priority levels to delay classes Low bandwidth urgent messages Realtime Non-realtime Priority

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

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

  22. Do we need non-work-conservation? • Can remove delay-jitter at an endpoint instead • but also reduces size of switch buffers… • Increases mean delay • not a problem for playback applications • Wastes bandwidth • can serve best-effort packets instead • 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

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

  24. Scheduling best-effort connections • Main requirement is fairness • 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

  25. Generalized Processor Sharing (GPS) • Main requirement is fairness (max-min fair allocates) • 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?

  26. More on GPS • GPS is ideal and unimplementable! • we cannot serve infinitesimal, only packets • 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 • 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))

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

  28. WFQ: first cut • 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 • 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 • 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 • Serve packets in order of finish numbers (≠ finish time)

  29. WFQ continued • To sum up, assuming we know the current round number R • 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?) • 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?)

  30. WFQ: computing the round number • 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 • this takes care of both problems (why?) • With this change, WFQ emulates GPS instead of bit-by-bit RR

  31. WFQ: computing the round number + • 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

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

  33. # active conversations - at arrival/departure Round number Problem: iterated deletion (cont) • 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 • problem in high speed networks • overcoming iterated deletion problem, • e.g. Self-clocked fair queuing (SCFQ)

  34. Evaluation • 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 • 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 • Since 1996, WFQ in Cisco, FORE, ..

  35. What does “fairness” divide between? • At what granularity? • Flows, connections, domains? • 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 • User = arbitrary granularity • Paper has a nice argument for (src, dst) pairs

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

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

  38. WFQ • WFQ also provides performance guarantees • 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 • assumes that the connection doesn’t send ‘too much’ more • precisely, connection should beleaky-bucketregulated • Parekh-Gallager theorem

  39. Parekh-Gallager theorem • Let it be leaky-bucket regulated such that # bits sent in time [t1, t2] <= ρ(t2 - t1) + σ • 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 largest packet allowed in the network be P

  40. Significance • Theorem shows that WFQ can provide end-to-end delay bounds • So WFQ provides both fairness and performance guarantees • 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

  41. Problems • 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 • but choosing leaky-bucket parameters is problematic

  42. Delay- EDD (Earliest Due Date) • EDD: packet with earliest deadline selected • 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 • Bandwidth at scheduler reserved at peak rate • Each packet gets a hard delay bound • 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

  43. Rate-controlled scheduling • 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 • Regulatorshapes the traffic, scheduler provides performance guarantees

  44. Summary • Two sorts of applications: best effort and guaranteed 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 • provided by WFQ, but this is expensive (low delay -> large b/w) • may be better to use rate-controlled schedulers • K-p253 Table

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

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

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

  48. Degree of aggregation (classify packets ) • 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 • Max-min fair allocation of buffers to classes • share buffer • drop packet from class with the longest queue (why?)

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

  50. 3. Early vs. late drop: RED • 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

More Related