Generalized Processing Sharing (GPS)

1. Generalized Processing Sharing (GPS) • Is work conserving • Is a fluid model • Service Guarantee • GPS discipline can provide an end-to-end bounded-delay service to a session whose traffic is constrained by a leaky bucket. • Fair Allocation • GPS can ensure fair allocation of bandwidth among all backlogged sessions regardless of whether or not their traffic is constrained. Thus, it is suitable for feedback based congestion control algorithms.

2. GPS Example • Red session has packets backlogged between time 0 and 10 • Other sessions have packets continuously backlogged 50% 10% 10% 10% 10% 10% 0 2 4 6 8 10 15

3. GPS • A work conserving GPS is defined as • where • Φi – weight of flow i • Wi(t1, t2) – total service received by flow i during [t1, t2) • W(t1, t2) – total service allocated to all flows during [t1, t2) • B(t1) – number of flows backlogged

4. Packet vs. Fluid System • GPS is defined in an idealized fluid model • multiple queues can be serviced simultaneously • no non-preemption unit • Real system are packet systems • one queue is served at any given time • packet transmission is not preempted • Goal • define packet algorithms approximating the fluid system • maintain most of the important properties

5. Fluid GPS system service order Weighted Fair Queueing select the first packet that finishes in GPS Approximating GPS with WFQ 0 2 4 6 8 10

6. Packet Approximation of Fluid System • Standard techniques of approximating fluid GPS • select packet that will finish first in GPS assuming that there are no future arrivals • Important properties of GPS • finishing order of packets currently in system independent of future arrivals • Implementation based on virtual time • assign virtual finish time to each packet upon arrival • packets served in increasing order of virtual times

7. System Virtual Time • Virtual time (VGPS) – service that backlogged flow with weight = 1 would receive in GPS

8. Service Allocation in GPS • The service received by flow i during an interval [t1,t2), while it is backlogged is

9. 0 0 4 4 8 8 12 12 16 16 System Virtual Time in GPS 1/2 1/8 1/8 1/8 1/8 Load = BW / 2 Load = BW

10. 0 4 8 12 16 Virtual Start and Finish Times Approximate the ideal distribution in a packet system Utilize the time the packets would start Sik and finish Fik in a fluid system pkt k Load = BW / 2 Load = BW

11. Virtual Time Implementation of WFQ • : virtual start time of the k-th packet on session j • : virtual finish time of the k-th packet on session j • : guaranteed rate for session j • : arrival time of the k-th packet on session j • :set of backlogged sessions in GPS system at time • service rate of session j in GPS at time is

12. Virtual Time Implementation of WFQ • Need to keep per flow instead of per packet virtual start, finish time only • System virtual time is used to reset a flow’s virtual start time when a flow becomes backlogged again after being idle If session j backlogged If session j unbacklogged

13. Research in Designing Packet Fair Queueing Algorithms • Improve worst-case fairness: important for hierarchical scheduler • use Smallest Eligible virtual Finish time First (SEFF) policy • examples: WF2Q, WF2Q+ • Reduce complexity • use simpler virtual time functions • examples: SCFQ, SFQ, DRR, FBFQ, leap-forward Virtual Clock, WF2Q+ • Improve resource allocation flexibility • Fair Service Curve • Implement in Combined Input Output Switch

14. Fluid GPS system service order Weighted Fair Queueing select the first packet that finishes in GPS Observation: packet finishes in WFQ no late than in GPS basis for proving delay bound for WFQ Another observation: some packet finishes service much earlier in WFQ in GPS Approximating GPS with WFQ 0 2 4 6 8 10

15. A More Accurate Approximation of GPS • Problem with WFQ • WFQ can be ahead of GPS too much • Worst-case Fair Weighted Fair Queueing (WF2Q) • a packet is eligible if it starts service in GPS • among all eligible packets, select the one that finishes first in GPS • optimal algorithm in approximating GPS • normalized WFI is one maximal size packet • WF2Q service order 50% 10% 10% 10% 10% 10% 0 2 4 6 8 10

16. Worst-case Packet Fair (I) • To quantify the discrepancy between the services provided by a packet discipline and the GPS discipline. • A service discipline s is called worst-case fair for session i if for any time , the delay of a packet arriving at is bounded above by , i.e., where is the throughput guarantee to sessioni, is the queue size of sessioniat time and is a constant independent of the queues of the other sessions sharing the multiplexer. A service discipline s is called worst-case fair if it is worst-case fair for all sessions. • Normalized Worst-case Fair Index for session iat server s: • Normalized Worst-case Fair Index for server s :

17. Worst-case Packet Fair (II) • GPS is worst-case fair with . • may increase linearly as a function of number of session n. In the example, consider the packet . It won’t depart until time , thus • The Normalized Worst-case Fair Index:

18. WF2Q • Is a packet approximation algorithm of GPS. • WF2Q provides almost identical service with GPS, the maximum difference is no more than one packet size. • Difference between WF2Q and WFQ • In a WFQ system, when the server chooses the next packet for transmission at time t, it selects among all the packets that are backlogged at t, and selects the first packet that would complete service in the corresponding GPS. • In a WF2Q system, when the server chooses the next packet at time t, it chooses only from the packets that have started receiving service in the corresponding GPS at t, and chooses the packet among them that would complete service first in the corresponding GPS.

19. Problem with WF2Q • The time complexity of implementing WF2Q is high. Because it’s based on a virtual time function which is defined with respect to the corresponding GPS system. It leads to considerable computational complexity due to the need for simulating events in the GPS system.

20. Virtual Time in Fluid GPS System Service Time • Virtual time function represents the cumulative fair amount of service • a previously idle session starts to receive service at the virtual time level when it becomes active • no compensation for the idle period • start receiving service immediately after becoming active • Accurate but difficult to compute • need to emulate fluid system, worst case complexity O(N) t1 Virtual Time (normalized service) previous idle session

21. Virtual Time in Packet System Time • Can we compute system virtual time based on information in the packet system? • no need to emulate fluid system • Normalized amounts of service received by backlogged sessions are different • Which level to set the previous idle session? Service t1 Virtual Time? (normalized service) previous idle session

22. Virtual Time in Packet System Service • Set too low: newly backlogged session receives more than its fair share, performance for other sessions degrade • Set too high: performance for newly backlogged session degrade • Tradeoff between accuracy and simplicity Time t1 Virtual Time? (normalized service) previous idle session

23. Heuristics of Computing Virtual Time in Packet System Service • SCFQ: virtual finish time of packet being serviced • SFQ: virtual start time of packet being serviced • WF2Q+: Time t1 Virtual Time? (normalized service) previous idle session

24. 1/2 1/2 1/8 1/8 1/8 1/8 1/8 1/8 1/8 1/8 Self Cock Fair Queuing (SCFQ) Packet Arrivals SCFQ [Golestani94] • System virtual time function • the finish time of the current packet being serviced • Packet selection policy • Smallest virtual Finish time First (SFF) 2 4 6 8 8 8 8 8 Smallest Finish time First (SFF)

25. 1/2 1/2 1/8 1/8 1/8 1/8 1/8 1/8 1/8 1/8 Start Time Fair Queuing (SFQ) Packet Arrivals SFQ • System virtual time function • the start time of the current packet being serviced • Packet selection policy • Smallest virtual Start time First (SSF) 0 2 4 6 0 0 0 0

26. 155 Mbps Link 100 Mbps 55 Mbps Provider 1 Provider 2 60 Mbps 40 Mbps CMU U.Pitt 30 Mbps 10 Mbps ECE Campus SCS seminar video seminar audio Distributed Simulation WEB Control Audio Video Hierarchical Resource Sharing • Resource contention/sharing at different levels • Resource management policies should be set at different levels, by different entities • resource owner • service providers • organizations • applications

27. Hierarchical Generalized Processor Sharing physical resource 100% • Idealized fluid algorithm • service multiple queues simultaneously, in proportional to shares • parent distributes service instantaneously to children GPS server 10% 10% 60% 10% 10% 50% 10%

28. H-GPS Example • Red session has packets backlogged between time 0 and 10 • Other sessions have packets continuously backlogged 60% 10% 10% 10% 10% 50% 10% 0 2 4 6 8 10 20

29. GPS and H-GPS Properties • Proven end-to-end delay bounds for guaranteed traffic • Adaptation friendly • no punishment in the future for using excess service • scalable technique for estimating excess bandwidth for adaptive applications • GPS: guaranteed service for each flow • H-GPS: guaranteed service for all classes • leaf class: individual flow • interior class: traffic aggregate • QoS met for all traffic classes simultaneously • ideal semantics for hierarchical resource management

30. Packet Approximation of H-GPS • Idea 1: use similar approach as approximating GPS • select packet finishing first in H-GPS, assuming there are no future arrivals • Problem • relative finish order of packets dependent on future arrivals • can not use virtual time implementation

31. H-GPS Example • Red session has packets backlogged between time 0 and 10 • Other sessions have packets continuously backlogged • Need to make a decision at time 11 60% 10% 10% 10% 10% 50% 10% 0 2 4 6 8 10 20

32. H-GPS: Decision at Time 11 • Red session has packets backlogged between time 0 and 10 • Other sessions have packets continuously backlogged • Need to make a decision at time 11 • Case 1: no future red arrivals • Case 2: red session active at time 11 • Relative finish order dependent on future arrivals 60% 10% 10% 10% 10% 50% 10% 0 2 4 6 8 10 20

33. 10 10 GPS PFQ 6 4 6 4 GPS GPS PFQ PFQ 1 3 1 3 2 2 GPS GPS GPS PFQ PFQ PFQ Packet Approximation of H-GPS • Idea 1 • select packet finishing first in H-GPS assuming there are no future arrivals • problem: • finish order in system dependent on future arrivals • virtual time implementation won’t work • Idea 2 • use a hierarchy of PFQ to approximate H-GPS H-GPS Packetized H-GPS

34. H-PFQ • Many PFQ algorithms • SCFQ, SFQ, FBFQ, WFQ • how do properties of PFQ relate to H-PFQ? • Worst-case Fair Index • measuring the accuracy of PFQ in approximating GPS • tight H-PFQ delay bound small WFI of PFQ • All previously proposed PFQ algorithms have large WFI’s

35. H-GPS and H-WFQ Example • Two levels of hierarchy • GPS order at top level • WFQ order at top level 50% 10% 10% 10% 10% 10% 5% 45% 0 2 4 6 8 10

36. H-GPS and H-WFQ Example • Arrival process • active at time 5 • all other flows continuously backlogged • Top level GPS server • Top level WFQ server at [0,4] • make decision assuming there are no future arrivals • select packets in class • only class is active • Class active at time 5 • has to endure a long delay 50% 10% 10% 10% 10% 10% 5% 45% 0 2 4 6 8 10

37. H-GPS and H-WF2Q Example • Arrival process • active at time 5 • all other flows continuously backlogged • Top level GPS server • Top level WFQ server • there are no future arrival • never ahead of GPS by one packet size • class receives service immediately after becoming active 50% 10% 10% 10% 10% 10% 5% 45% 0 2 4 6 8 10

38. WF2Q+ • WFQ and WF2Q • need to emulate fluid GPS system • high complexity • WF2Q+ • provide same delay bound and WFI as WF2Q • lower complexity

39. Example Hierarchy

40. Uncorrelated Cross Traffic Delay under H-WFQ Delay under H-SCFQ 60ms 40ms 20ms Delay under H-WF2Q+ Delay under H-SFQ 60ms 40ms 20ms

41. Correlated Cross Traffic Delay under H-WFQ Delay under H-SCFQ 60ms 40ms 20ms Delay under H-WF2Q+ Delay under H-SFQ 60ms 40ms 20ms