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

2. Outline Overview & background Overview & background Model Model Request typeRequest type Request Class & priorityRequest Class & priority Network topologyNetwork topology Proposed Heuristic Proposed Heuristic Session Type Request SchedulingSession Type Request Scheduling Data Type Request SchedulingData Type Request Scheduling Simulation & Evaluation Simulation & Evaluation

3. Overview An online heuristic to perform bandwidth allocation in preemptive networks to maximize the worth of the requests satisfied. 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 arrivesOnline: make decision base on the information when request arrives Preemptive: Preempt scheduled requests to accommodate requests that “ worth more ”Preemptive: Preempt scheduled requests to accommodate requests that “ worth more ” Worth: a weight decided by the class and priority of the data transmissionWorth: a weight decided by the class and priority of the data transmission Goal: maximize the total worth of scheduled requestsGoal: maximize the total worth of scheduled requests

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

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

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

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

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

9. Complexity of the Problem Two NP-complete problems 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 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 requestSelecting 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 Scheduling event is triggered for a batch of requests Sort the requests Sort the requests Group by classGroup by class Separated by the request type in each class, session type first (why?)Separated by the request type in each class, session type first (why?) For each type, further sort by worth-per-bit (=worth/size)For each type, further sort by worth-per-bit (=worth/size) Allocate the bandwidth request-by-request Allocate the bandwidth request-by-request

11. Session Type Request Scheduling Five cases: Five cases: Unutilized bandwidth is sufficient for the new request, accept.Unutilized bandwidth is sufficient for the new request, accept. Bandwidth consumed by all scheduled session type requests with class < C r plus the bandwidth requested by r exceeds the capacity of the link, reject.Bandwidth consumed by all scheduled session type requests with class < C r plus the bandwidth requested by r exceeds the capacity of the link, reject. Need to reposition data type requests of more important classNeed to reposition data type requests of more important class Preempt requests of less important classesPreempt requests of less important classes Preempt requests of the same classPreempt 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) 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 Rules If preemption is needed while repositioning, only requests that are of class > C r is allowed to be preempted.If preemption is needed while repositioning, only requests that are of class > C r is allowed to be preempted. Consider repositioning the blocking data request(s) occupying the maximum bandwidthConsider 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 < C r may be required.If the bandwidth released by repositioning is not enough for r, preemption of other requests of class < C r 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 > C r is not clear. All data type requests that are active during the period of r? How to decide the set ofk data type request(s) to be repositioned before the preemption of other request of class > C r is not clear. All data type requests that are active during the period of r? How to reposition a data type request could be tricky 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.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 > C r before doing any preemption caused by repositioning? - If you preempt all requests of class > C r first, come repositioning might not be necessary.Preempt all requests of class > C r before doing any preemption caused by repositioning? - If you preempt all requests of class > C r first, come repositioning might not be necessary. The preemption caused by repositioning might be time consuming. 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. 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 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. 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 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 Problems Again, consider the overlap at the critical part instead of the duration of r?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 ” ?“ 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 the bandwidth released for the time out of the duration of new request? Why not consider repositioning requests of same class?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 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 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 Add all preempted requests that have not begun transmission to the unscheduled_requests list

16. Post-preemption Scheduler Triggered by requests scheduled with preemption Triggered by requests scheduled with preemption Attempt to allocate excess preempted capacity to requests in the unscheduled_requests list Attempt to allocate excess preempted capacity to requests in the unscheduled_requests list Run the same heuristic Run the same heuristic This iteration may take long time to stop This iteration may take long time to stop Go through the unschduled_requests list to schedule call one by oneGo through the unschduled_requests list to schedule call one by one Preemption during the scheduling will add new preempted requests into the listPreemption 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 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 size r /(d r -a r ) Schedule r with preemption by treating it like a session type request with a bandwidth need give by size r /(d r -a r ) Most “ flexible ”Most “ flexible ” Might need to preempt more scheduled requestsMight need to preempt more scheduled requests Use the same preemption related rules as session type request Use the same preemption related rules as session type request Does NOT cause any repositioning Does NOT cause any repositioning Save scheduling timeSave scheduling time Why choose to save time here instead of session type requests?Why choose to save time here instead of session type requests?

18. Performance Comparisons Complete Sharing Complete Sharing FCFSFCFS Loose Upper Bound Loose Upper Bound Sum up the weighted priorities of all requestsSum up the weighted priorities of all requests Ingress and Egress Upper Bounds Ingress and Egress Upper Bounds Sort all requests from t earliest to t latest by class an priority. Satisfy the requests in sorted order until exceeding the maximum allocable bits (bw link * (t latest -t earliest )) for each Ingress/Egress linkSort all requests from t earliest to t latest by class an priority. Satisfy the requests in sorted order until exceeding the maximum allocable bits (bw link * (t latest -t earliest )) for each Ingress/Egress link AssumptionsAssumptions No conflict between ingress & egress links No conflict between ingress & egress links No conflict among the requests No conflict among the requests Assumptions not true in most case. Depends on the arrival distribution 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 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 three classes and four priority levels within each class Uniformly distributed among all 15 nodes Uniformly distributed among all 15 nodes Sample size = 2000 requests Sample size = 2000 requests Arrival of requests is Poisson, two loading factors: 0.7 and 1.2 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 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?) 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: Main operations in the heuristic: Sorting – sort request by worth-per-bit after grouping by class and typeSorting – sort request by worth-per-bit after grouping by class and type Preemption – schedule more important request by preempt scheduled less important requestsPreemption – schedule more important request by preempt scheduled less important requests Data repositioning – Reposition data type request to accommodate session requestsData repositioning – Reposition data type request to accommodate session requests Three different version of heuristics: Three different version of heuristics: SortSort Sort + preemptSort + preempt Full: sort + preempt + repositionFull: sort + preempt + reposition Two load factors: 0.7 & 1.2 Two load factors: 0.7 & 1.2 Two values of w (weighting constant used to decide priority): 2 & 10 Two values of w (weighting constant used to decide priority): 2 & 10

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

23. Simulation Results Comparison of the performance with different w 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 Total number of preemptions and repositions generated More preemptions on class 2 than class 3More preemptions on class 2 than class 3 Possibly because more class 2 requests are scheduledPossibly because more class 2 requests are scheduled

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

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