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.

GPS Example %10% Red session has packets backlogged between time 0 and 10 Other sessions have packets continuously backlogged

GPS A work conserving GPS is defined as where –Φ i – weight of flow i –W i ( t 1, t 2 ) – total service received by flow i during [ t 1, t 2 ) –W ( t 1, t 2 ) – total service allocated to all flows during [ t 1, t 2 ) –B(t 1 ) – number of flows backlogged

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

Approximating GPS with WFQ Fluid GPS system service order Weighted Fair Queueing –select the first packet that finishes in GPS

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 Packet Approximation of Fluid System

System Virtual Time Virtual time ( V GPS ) – service that backlogged flow with weight = 1 would receive in GPS

Service Allocation in GPS The service received by flow i during an interval [ t 1,t 2 ), while it is backlogged is

System Virtual Time in GPS Load = BW /2 1/8 Load = BW / 2

Virtual Start and Finish Times Approximate the ideal distribution in a packet system Utilize the time the packets would start S i k and finish F i k in a fluid system Load = BW Load = BW / 2 pkt k

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

Virtual Time Implementation of WFQ If session j backlogged If session j unbacklogged 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

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: WF 2 Q, WF 2 Q+ Reduce complexity –use simpler virtual time functions –examples: SCFQ, SFQ, DRR, FBFQ, leap-forward Virtual Clock, WF 2 Q+ Improve resource allocation flexibility –Fair Service Curve Implement in Combined Input Output Switch

Approximating GPS with WFQ 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

A More Accurate Approximation of GPS 50%10% Problem with WFQ –WFQ can be ahead of GPS too much Worst-case Fair Weighted Fair Queueing (WF 2 Q) –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 WF 2 Q service order

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 session i, is the queue size of session i at 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 i at server s: Normalized Worst-case Fair Index for server s :

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:

WF 2 Q Is a packet approximation algorithm of GPS. WF 2 Q provides almost identical service with GPS, the maximum difference is no more than one packet size. Difference between WF 2 Q 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 WF 2 Q 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.

Problem with WF 2 Q The time complexity of implementing WF 2 Q 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 (normalized service) t1t1 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) previous idle session

21 Virtual Time in Packet System Service Time Virtual Time? (normalized service) t1t1 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? previous idle session

22 Virtual Time in Packet System Service Time Virtual Time? (normalized service) t1t1 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 previous idle session

23 Heuristics of Computing Virtual Time in Packet System Service Time Virtual Time? (normalized service) t1t1 SCFQ: virtual finish time of packet being serviced SFQ: virtual start time of packet being serviced WF 2 Q+: previous idle session

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

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

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 Link Provider 1 seminar video ECE SCS U.PittCMU Provider 2 Distributed Simulation WEB VideoAudioControl 155 Mbps 40 Mbps60 Mbps 10 Mbps30 Mbps 100 Mbps55 Mbps Campus seminar audio

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

H-GPS Example 50%10% Red session has packets backlogged between time 0 and 10 Other sessions have packets continuously backlogged 60%

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

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

H-GPS Example 50%10% 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%

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 50% 10% 60%

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 GPS PFQ 10 PFQ Packetized H-GPS H-GPS

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 H-PFQ

H-GPS and H-WFQ Example 50% 10% Two levels of hierarchy GPS order at top level WFQ order at top level % 45%

H-GPS and H-WFQ Example 50% 10% 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 % 45%

H-GPS and H-WF 2 Q Example 50% 10% 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 % 45%

WF 2 Q+ WFQ and WF 2 Q –need to emulate fluid GPS system –high complexity WF 2 Q+ –provide same delay bound and WFI as WF 2 Q –lower complexity

Example Hierarchy

Uncorrelated Cross Traffic Delay under H-WFQ Delay under H-WF 2 Q+ Delay under H-SFQ Delay under H-SCFQ 20ms 60ms 40ms 20ms 60ms 40ms

Correlated Cross Traffic Delay under H-WFQ Delay under H-WF 2 Q+ Delay under H-SFQ Delay under H-SCFQ 20ms 60ms 40ms 20ms 60ms 40ms