Presented by Xiangfei Zhu xzhu@cs.virginia Jan 2005

1. Dynamic Resource Allocation for Classes of Prioritized Session and Data Requests in Preemptive Heterogeneous Networks Amit Naik, Howard Jay Siegel, Edwin K.P. Chong Presented by Xiangfei Zhu xzhu@cs.virginia.edu Jan 2005

2. Outline • Overview & background • Model • Request type • Request Class & priority • Network topology • Proposed Heuristic • Session Type Request Scheduling • Data Type Request Scheduling • Simulation & Evaluation

3. Overview • An online heuristic to perform bandwidth allocation in preemptive networks to maximize the worth of the requests satisfied. • Online: make decision base on the information when request arrives • Preemptive: Preempt scheduled requests to accommodate requests that “worth more” • Worth: a weight decided by the class and priority of the data transmission • Goal: maximize the total worth of scheduled requests

4. Background • Part of Agile Information Control Environment (AICE) project sponsored by DARPA/ITO • Manage and control information flows for military operations in distributed computing environments. • Commercial concept of price corresponds to priorities of data transmissions in military environments

5. Request Types • Data type • Request a data item of given size • Parameters • Available time • Deadline • Size • Maximum bandwidth (limited by clients capability) • Session type • Request a fixed amount bandwidth for a given interval of time • Parameters • Begin time • Finish time • Bandwidth request

6. Class and Priority Level • 3 classes: 1 to 3 • 4 priority levels within each class: 1 to 4 • Criterion of the effectiveness of bandwidth allocation heuristics • At first only the collective worth of class 1 requests are considered • Class i+1 requests are considered only when class i is a tie

7. Worth • Worth – weighted priority • Worth of level i request is given by w4-i, w=2 or 10

8. Network Topology • Each node is associated with multiple applications • Each node has an ingress link and an egress link • Assume network backbone has sufficient bandwidth

9. Complexity of the Problem • Two NP-complete problems • Selecting the optimal set of requests to be satisfied, given that three or more of their parameters (available time, deadline, request size, priority level…) can vary simultaneously. • Selecting the optimal set of requests to preempt to schedule a new request

10. Proposed Heuristic – Overview • Scheduling event is triggered for a batch of requests • Sort the requests • Group by class • Separated by the request type in each class, session type first (why?) • For each type, further sort by worth-per-bit (=worth/size) • Allocate the bandwidth request-by-request

11. Session Type Request Scheduling • Five cases: • Unutilized bandwidth is sufficient for the new request, accept. • Bandwidth consumed by all scheduled session type requests with class < Crplus the bandwidth requested by r exceeds the capacity of the link, reject. • Need to reposition data type requests of more important class • Preempt requests of less important classes • Preempt requests of the same class

12. Reposition data type requests of more important classes • Reposition: schedule a data type request in a time window that does not overlap with the duration of the request r (eg: smaller time interval with higher bandwidth) • Rules • If preemption is needed while repositioning, only requests that are of class > Cr is allowed to be preempted. • Consider repositioning the blocking data request(s) occupying the maximum bandwidth • If the bandwidth released by repositioning is not enough for r, preemption of other requests of class < Cr may be required.

13. Reposition data type requests of more important classes - Problems • How to decide the set ofk data type request(s) to be repositioned before the preemption of other request of class > Cris not clear. All data type requests that are active during the period of r? • How to reposition a data type request could be tricky • Avoid the period of request r or only avoid the critical part? – Hard to decide when repositioning of multiple requests are needed. • Preempt all requests of class > Cr before doing any preemption caused by repositioning? - If you preempt all requests of class > Cr first, come repositioning might not be necessary. • The preemption caused by repositioning might be time consuming. • Repositioning data type request might need to coordinate with end host because end host might need to be in certain state during the request period.

14. Preempt requests of same class • Start with request with the lowest priority • For requests with same priority, select the request that occupies more bandwidth in the duration of new request. • Preempt the candidate requests and schedule the new request r only if the sum of the weighted priorities of the candidate requests is less than the weighted priorities of r • Problems • Again, consider the overlap at the critical part instead of the duration of r? • “This ensures that for the same loss of worth of a preempted request, a higher bandwidth is released”? • Why not consider the bandwidth released for the time out of the duration of new request? • Why not consider repositioning requests of same class?

15. Preempt requests of less important classes • Start with the requests of the lowest weighted priority within the least important class • Do preemption until the preempted bandwidth + unused bandwidth >= bandwidth needed by r • Add all preempted requests that have not begun transmission to the unscheduled_requests list

16. Post-preemption Scheduler • Triggered by requests scheduled with preemption • Attempt to allocate excess preempted capacity to requests in the unscheduled_requests list • Run the same heuristic • This iteration may take long time to stop • Go through the unschduled_requests list to schedule call one by one • Preemption during the scheduling will add new preempted requests into the list

17. Data Type Request Scheduling • Try to schedule r using the unused bandwidth, start with longest contiguous block of time • Schedule r with preemption by treating it like a session type request with a bandwidth need give by sizer/(dr-ar) • Most “flexible” • Might need to preempt more scheduled requests • Use the same preemption related rules as session type request • Does NOT cause any repositioning • Save scheduling time • Why choose to save time here instead of session type requests?

18. Performance Comparisons • Complete Sharing • FCFS • Loose Upper Bound • Sum up the weighted priorities of all requests • Ingress and Egress Upper Bounds • Sort all requests from tearliest to tlatest by class an priority. Satisfy the requests in sorted order until exceeding the maximum allocable bits (bwlink * (tlatest-tearliest)) for each Ingress/Egress link • Assumptions • No conflict between ingress & egress links • No conflict among the requests • Assumptions not true in most case. Depends on the arrival distribution

19. Simulation Parameters • Equal probability of being either of data type or session type • Uniformly distributed among three classes and four priority levels within each class • Uniformly distributed among all 15 nodes • Sample size = 2000 requests • Arrival of requests is Poisson, two loading factors: 0.7 and 1.2

20. Simulation Parameters • Session bandwidth, data duration, and lead time are uniformly distributed • Session duration and data size are heavy-tailed but truncated at certain high-end. (bounded Pareto?)

21. Versions of the Heuristic Simulated • Main operations in the heuristic: • Sorting – sort request by worth-per-bit after grouping by class and type • Preemption – schedule more important request by preempt scheduled less important requests • Data repositioning – Reposition data type request to accommodate session requests • Three different version of heuristics: • Sort • Sort + preempt • Full: sort + preempt + reposition • Two load factors: 0.7 & 1.2 • Two values of w (weighting constant used to decide priority): 2 & 10

22. Simulation Results Load factor = 1.2W = 10 Load factor = 0.7W = 10 • The greater the loading of the system, more is the advantage obtained from an intelligent allocation • “Sorting + preemption” comes very close to the ingress/egress upper bounds • Full heuristic shows improvement for class 2 and 3

23. Simulation Results • Comparison of the performance with different w • The larger the w, the more level 1 request accepted (not very clear from the plot)

24. Simulation Results • Total number of preemptions and repositions generated • More preemptions on class 2 than class 3 • Possibly because more class 2 requests are scheduled

25. Recap • Focus on the on-line scheduling of bandwidth requests with different class and priority • Use sorting, preemption and repositioning as tools • Simulation result is compared with FCFS & ingress/egress upper bounder

26. Problems & Limitations • Model • A simplifying assumption: backbone has sufficient bandwidth • End-to-end multi-hop resource allocation is reduced to two links • Concurrency control between the allocation of the ingress/egress link is not clear. Centralized? • Heuristic • Too many preemptions • Starvation • Low utilization • Decisions of many trade-offs have no explanation • May take long time to finish a schedule • Evaluation • Only one metric: sum of the weighted priorities of the satisfied requests. • No evaluation on the complexity/performance of different versions of the heuristics • Reference models for comparison are very simple • Requests distribution is too ideal, many uniform distributions, which makes the simulation result close to ingress/egress upper bounder