A φ-Competitive Algorithm for Scheduling Packets with Deadlines

07/18/2018 ∙ by Pavel Veselý, et al. ∙ Charles University in Prague University of California, Riverside Akademia Sztuk Pięknych we Wrocławiu University of Warwick 0

In the online packet scheduling problem with deadlines (PacketScheduling, for short), the goal is to schedule transmissions of packets that arrive over time in a network switch and need to be sent across a link. Each packet p has a deadline d_p, representing its urgency, and a non-negative weight w_p, that represents its priority. Only one packet can be transmitted in any time slot, so, if the system is overloaded, some packets will inevitably miss their deadlines and be dropped. In this scenario, the natural objective is to compute a transmission schedule that maximizes the total weight of packets which are successfully transmitted. The problem is inherently online, with the scheduling decisions made without the knowledge of future packet arrivals. The central problem concerning PacketScheduling, that has been a subject of intensive study since 2001, is to determine the optimal competitive ratio of online algorithms, namely the worst-case ratio between the optimum total weight of a schedule (computed by an offline algorithm) and the weight of a schedule computed by a (deterministic) online algorithm. We solve this open problem by presenting a ϕ-competitive online algorithm for PacketScheduling (where ϕ≈ 1.618 is the golden ratio), matching the previously established lower bound.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

In the online packet scheduling problem with deadlines (PacketScheduling, for short), the goal is to schedule transmissions of packets that arrive over time in a network switch and need to be sent across a link. Each packet has a deadline , representing its urgency, and a non-negative weight , that represents its priority. (These priorities can be used to implement various levels of service in networks with QoS guarantees.) Only one packet can be transmitted in any time slot, so, if the system is overloaded, some packets will inevitably miss their deadlines and be dropped. In this scenario, the natural objective is to compute a transmission schedule that maximizes the total weight of packets which are successfully transmitted. In the literature this problem is also occasionally referred to as bounded-delay buffer management, QoS buffering, or as a job scheduling problem for unit-length jobs with release times, deadlines, and weights, where the objective is to maximize the weighted throughput.

In practice, scheduling of packets must be accomplished online, with the scheduling decisions made without the knowledge of future packet arrivals. The central problem concerning PacketScheduling, that has been a subject of intensive study since 2001, is to determine the optimal competitive ratio of online algorithms, namely the worst-case ratio between the optimum total weight of a schedule (computed by an offline algorithm) and the weight of a schedule computed by a (deterministic) online algorithm.

This paper provides the solution of this open problem by establishing an upper bound of on the competitive ratio for PacketScheduling (where is the golden ratio), matching the previously known lower bound [16, 3, 21, 10]. Our -competitive algorithm PlanM is presented in Section 4. The basic idea underlying our algorithm is relatively simple. It is based on the concept of the plan, which, at any given time , is the maximum-weight subset of pending packets that can be feasibly scheduled in the future (if no other packets arrive); we describe it in Section 3. When some packet from the plan is chosen to be scheduled at time , it will be replaced in the plan by some other packet . The algorithm chooses to maximize an appropriate linear combination of and . For technical reasons, it also makes additional changes in the plan, adjusting deadlines and weights of some packets. While the algorithm itself is not complicated, its competitive analysis given in Section 5, is quite intricate. It relies on showing a bound on amortized gain at each step, using a potential function, which quantifies the advantage of the algorithm over the adversary in future steps, and on maintaining an invariant that allows us to control decreases of the potential function.

Past work. The PacketScheduling problem was first introduced independently by Hajek [16] and Kesselman et al. [18], who both gave a proof that the greedy algorithm (that always schedules the heaviest packet) is -competitive. Hajek’s paper also contained a proof of a lower bound of on the competitive ratio. The same lower bound was later discovered independently by Andelman et al. [3, 21] and also by Chin et al. [10] in a different, but equivalent setting. Improving over the greedy algorithm, Chrobak et al. [11, 12] gave an online algorithm with competitive ratio . This was subsequently improved to by Li et al. [20], and to by Englert and Westermann [14], which, prior to the present paper, has been the best upper bound known.

Algorithms with ratio have been developed for several restricted variants of PacketScheduling. Li et al. [19] (see also [17]) gave a -competitive algorithm for the case of agreeable deadlines, which consists of instances where the deadline ordering is the same as the ordering of release times. Another well-studied case is that of -bounded instances, where each packet’s deadline is within at most steps from its release time. A -competitive algorithm for -bounded instances was given by Kesselman et al. [18]. This bound was later extended to -bounded instances by Chin et al. [9] and to -bounded instances by Böhm et al. [8]. The work of Bienkowski et al. [6] provides an upper bound of (in a somewhat more general setting) for the case where packet weights increase with respect to deadlines. (It should be noted that the lower bound of applies to instances that are -bounded, which implies agreeable-deadlines, and have increasing weights.) In -uniform instances, the deadline of each packet is exactly steps from its release time, which also implies the agreeable deadlines property. The lower bound of in [16, 10] does not apply to -uniform instances; in fact, as shown by Chrobak et al. [12], for -uniform instances ratio is optimal.

Randomized online algorithms for PacketScheduling have been studied as well, although the gap between the upper and lower bounds for the competitive ratio remains quite large. The best upper bound is  [4, 9, 7, 22], and it applies even to the adaptive adversary model. For the adaptive adversary the best lower bound is  [7], while for the oblivious adversary it is  [10].

Kesselman et al. [18] originally proposed the problem in the setting with integer bandwidth , which means that packets are sent in each step. For any they proved that the greedy algorithm is -competitive and that there is a -competitive algorithm for -bounded instances [18]. Later, Chin et al. [9] gave an algorithm with ratio that tends to for . The best lower bound for any , also due to Chin et al. [9], equals and holds even for randomized algorithms against the oblivious adversary. Observe that any upper bound for bandwidth  implies the same upper bound for an arbitrary , by simulating an online algorithm for bandwidth  on an instance where each step is subdivided into smaller steps. Hence, our algorithm in Section 4 is -competitive for any , which improves the current state-of-the-art for any .

There is a variety of other packet scheduling problems related to PacketScheduling. The semi-online setting with lookahead was proposed in [8]. A relaxed variant of PacketScheduling in which only the ordering of deadlines is known, but not their exact values, was studied in [5], where a lower bound higher than was shown. In the FIFO model (see, for example, [2, 18]), packets do not have deadlines, but the switch has a buffer that can only hold packets, and packets must be transmitted in the first-in-first-out order. More information about PacketScheduling and related scheduling problems can be found in a survey paper by Goldwasser [15].

2 Preliminaries

The online PacketScheduling problem. The instance of PacketScheduling is specified by a set of packets, with each packet represented by a triple , where integers and denote the release time and deadline (or expiration time) of , and is the weight of . (To avoid double indexing, we sometimes use notation to denote and for .) Time is discrete, with time units represented by consecutive integers that we refer to as time slots or steps. In a feasible transmission schedule, a subset of packets is transmitted. Only one packet can be transmitted in each time step, and each packet can only be transmitted in one slot in the interval . The objective is to compute a schedule whose total weight of transmitted packets (also called its profit) is maximized.

In the online variant of PacketScheduling, which is the focus of our work, the algorithm needs to compute the solution incrementally over time. At any time step , packets with release times equal to are revealed and added to the set of pending packets (that is, those that are already released, but not yet expired or transmitted). Then the algorithm needs to choose one pending packet to transmit in slot . As this decision is made without the knowledge of packets to be released in future time steps, such an online algorithm cannot, in general, be guaranteed to compute an optimal solution. The quality of the schedules it computes can be then quantified using competitive analysis. We say that an online algorithm is -competitive if, for each instance, the optimal profit (computed offline) is at most times the profit of the schedule computed by the online algorithm.

Useful assumptions. We make two assumptions about our problem without loss of generality.

  1. We assume that at each step and for each (up to a certain large enough limit), there is a pending packet with deadline (or more such packets, if needed). This can be achieved by releasing, at time , virtual -weight packets with deadline , for each sufficiently large .

  2. We also assume that all packets have different weights. Any instance can be transformed into an instance with distinct weights through infinitesimal perturbation of the weights, without affecting the competitive ratio. Thus the -weight packets from the previous assumption have, in fact, infinitesimal positive weights. The purpose of this assumption is to facilitate consistent tie-breaking, in particular uniqueness of plans (to be defined shortly).

3 Plans

Consider an execution of an online algorithm. At any time , the algorithm will have a set of pending packets. We now discuss properties of these pending packets and introduce the concept of a plan.

The set of packets pending at a time has a natural ordering, called the canonical ordering and denoted , which orders packets in non-decreasing order of deadlines, breaking ties in favor of heavier packets. (By assumption ii the weights are distinct.) Formally, for two pending packets and , define iff or and . The earliest-deadline packet in some subset of pending packets is the packet that is the first in the canonical ordering of . Similarly, the latest-deadline packet in is the last packet in the canonical ordering of .

Consider a set of packets pending at a time step . is called feasible if the packets in can be scheduled in future time slots , meeting their deadlines. Using a standard exchange argument, if is feasible, then any schedule of can be converted into its canonical schedule, in which the packets from are assigned to the slots in the canonical order.

If is an interval of yet-unexpired time slots, , by we denote the subset of consisting of packets whose deadline is in . In particular, contains packets with deadlines at most . We also define

Note that is the number of slots in interval . For convenience, we also allow , in which case the above formula gives us that . The values of are useful for determining feasibility of :

Observation 3.1.

Let be a subset of packets pending at some step . is feasible if and only if for each .

This observation is quite straighforward: If is feasible then, in any schedule of , for each all packets in are scheduled in ; thus . For the other direction, the condition that for each implies, by simple induction, that if we assign the packets in to slots in the canonical order, this will produce a schedule (the canonical schedule of , in fact) in which all packets will meet their deadlines.

Given the set of packets pending at a given time , the plan is defined as the maximum-weight feasible subset of pending packets. Since the collection of feasible subsets of pending packets forms a matroid (which is easy to verify using Observation 3.1; see also e.g. [18]), the plan can be computed by the following greedy algorithm:

1:Let be the set of packets pending at step
2:
3:for each packet in order of decreasing weights do
4:     if  for all  then
5:               
6: is the plan
Algorithm 1 Algorithm 

Assumption ii about different weights implies that the plan computed above is unique. We typically use letters to denote plans. Note that in a plan we do not assign packets to time slots, that is, a plan is not a schedule. A plan has at least one schedule, but in general it may have many. (In the literature, such scheduled plans are sometimes called optimal provisional schedules.)

Figure 3.1: An example of an instance with plan . Note that packet is not in the plan, even though it is heavier than . The segments of are , , . (Alternatively, in terms of packets from , these segments are , , .) The values of are: for , and for . The figure also shows the canonical schedule of plan .

We briefly describe the structure of plan at time . (See Appendix A.1 for details and Figure 3.1 for illustration.) Slot is called tight in if . According to our convention for , we also consider to be a tight slot. If the tight slots of are , then for each the time interval is called a segment of . In words, the tight slots divide the plan into segments, each starting right after a tight slot and ending at (and including) the next tight slot. The significance of a segment is that in any schedule of all packets in with deadlines in must be scheduled in this segment. Thus, slightly abusing terminology, we occasionally think of each segment as a set of packets, namely the packets in that must be scheduled in the segment. Within a segment, packets from can be permuted, although only in some restricted ways. In particular, the first slot of a segment may contain any packet from that segment (see Observation A.1). By we denote the initial segment of ; this segment will play a special role in our algorithm.

For a plan and a slot , let be the earliest tight slot (which exists by Assumption i), and let be the latest tight slot (which is well-defined because is a tight slot).

The notion that will be crucial in the design of our -competitive algorithm is the minimum weight of a packet that can appear in a schedule of the plan in some slot between the current time and . Naturally, the packets that are candidates for this minimum include all packets in segments ending before , but also we need to include all packets in the segment of , even those with deadlines larger than . (This is because, as explained earlier, each packet in a segment can be scheduled at the beginning of that segment.) Formally, for a plan at time and a slot , define

We will occasionally omit in this notation, if it is understood from context. By definition, if we fix and and think of as a function of , then this function is monotonely non-increasing over the whole range of , and is constant in each segment (that is, all slots in any given segment have the same value of ). Moreover, if then .

To analyze how the plan changes over time, we divide each step into a sequence of events. First we have events representing packet arrivals, with all packets released at time being added to the set of pending packets, one by one. The last event represents scheduling a packet for transmission and incrementing the current time to . The matroid property implies that at most one packet in the plan changes after each event (not counting the scheduled packet in a scheduling event). These changes are fairly straightforward and we outline them briefly below; for a formal description of these changes and correctness proofs see Appendix A.1.

In the discussion below we assume that is the current time step, is the current plan, right before an event, and is the plan after the event. For a slot , whenever we refer to the change of (that it increases, decreases, or remains the same), without specifying the plan, we mean the change from to . We use the same convention for function .

Packet arrival. We first consider the event of a new packet arriving at time . As is added to the set of pending packets, the plan needs to be updated accordingly. Define to be the packet with , that is the lightest packet in with . If , then is not added to the plan and the plan stays the same, while if , then is added to the plan and is forced out, i.e., the new plan is . In the latter case, it is interesting to see how the values of and the segments change:

  • If , then for . Therefore, all tight slots in are no longer tight and the segments containing and and all segments in-between get merged into one segment of .

  • If , then and must be in the same segment of (because ) and for . Thus there may be new tight slots in , resulting in new segments.

In both cases, the values of remain the same for other slots , thus other tight slots and segments do not change. Moreover, holds for any slot . (This property will play a significant role in our algorithm.)

Scheduling a packet. Next, we discuss a scheduling event. Thus now is the plan at time after all packets arriving at time are aleady added to the set of pending packets. Suppose that we decide to schedule a packet at time . (Throughout the paper, only packets in the plan will be considered for scheduling.) As before, is the plan after this event, that is after is scheduled and the current time is incremented to .

If is from the first segment of , then . In this case for and remains unchanged for . This implies that new tight slots may appear before , i.e., the first segment may get divided into more segments. Furthermore, does not decrease for any .

The more interesting case is when is from a later segment. Let be the lightest packet in and let be the heaviest pending packet not in that satisfies . Using the matroid property of the feasible sets of packets at time and the structure of the plan, in Appendix A.1 we prove that . Further, in this case we have:

  • for . There may be new tight slots in the interval , resulting in new segments.

  • If , then for . Here, all segments that overlap are merged into one segment of .

  • If , then for . (In this case and must be in the same segment of , because .) As a result of decreasing some values, new tight slots may appear in , creating new segments.

For slots not covered by the cases above, the value of does not change. Unlike for packet arrivals, after a packet scheduling event some values of may decrease, either due to being included in or as a side-effect of segments being merged.

The aforementioned updates of the plan motivate the following definition: Let be the plan at time . For each we define the substitute packet of , denoted , as follows. If , then , where is the lightest packet in . If , then is the heaviest pending packet that satisfies (it exists by assumption i).

By definition, all packets in a segment of have the same substitute packet. Also, for any it holds that . This is because for we have and , while for we have ; thus in this case, the set is feasible and the optimality of implies that .

4 Online Algorithm

Intuitions. For profit maximization problems, the challenge in the online setting is to balance the immediate profit against future profits. Let be the plan at step . Consider the greedy algorithm for PacketScheduling, which at time schedules the heaviest pending packet (which is necessarily in ). As a result, in the next step would be replaced in the plan by its substitute packet , which could be very light, possibly . Suppose that there is another packet in the plan with whose substitute packet is quite heavy, say . Thus instead of we can schedule at time , gaining about as much as from in step , but with essentially no decrease in the plan’s total weight. This example indicates that a reasonable strategy would be to choose a packet based both on its weight and the weight of its substitute packet. Following this intuition, our algorithm chooses that maximizes , breaking ties arbitrarily.111 The choice of the coefficients can be derived from analyzing the -bounded case. Interestingly, there is another linear combination that gives ratio for the -bounded case, namely , but we were not able to make this one work in the general case.

As it turns out, the above strategy for choosing does not, by itself, guarantee -competitiveness. The analysis of special cases and an example where this simple approach fails leads to the second idea behind our algorithm. The difficulty is related to how the values of , for a fixed , vary while the current time increases. We were able to show -competitiveness of the above strategy for certain instances where monotonely increases as grows from to . We call this property slot-monotonicity. To extend it to instances where slot monotonicity does not hold, the idea is then to simply force it to hold by decreasing deadlines and increasing weights of some packets in the new plan. (To avoid unfairly benefiting the algorithm from these increased weights, we will need to account for them appropriately in the analysis.) From this point on, the algorithm proceeds using these new weights and deadlines when computing the plan and choosing a packet for transmission.

Notation. To avoid ambiguity, we will index various quantities used by the algorithm with the superscript that represents the current time. This includes weights and deadlines of some packets, since, as described above, these might change over time.

  • We use notation and for the weight and the deadline of packet in step , before a packet is scheduled. (Our algorithm only changes weights and deadlines when scheduling a packet, so they are not affected by packet arrivals.) To avoid double subscripts, we occasionally write and instead of and . By we denote the original weight of packet . We may omit in these notations when is unambiguously implied from context.

  • is the plan at (the current) time after all packets with arrive and before a packet is scheduled. Recall that by we denote the initial segments of .

  • is the lightest packet in in the first segment .

  • We use to denote and we adopt similar convention for , and .

1:schedule packet that maximizes
2:if  then “leap step”
3:     
4:      increase
5:      and
6:      and
7:     while  do
8:         
9:          heaviest packet in with
10:         
11:          and      
12:      final value of
Algorithm 2 Algorithm 

The pseudo-code of our algorithm, called , is given in Algorithm 2. For a pending packet , if , resp.  is not explicitly set in the algorithm, then , resp. , i.e., the weight, resp. the deadline remains the same by default.

Let be the packet sent by PlanM in step . If is in the first segment of , the step is called an ordinary step. Otherwise (if ) the step is called a leap step, and then is the heaviest pending packet with . We will further consider two types of leap steps. If and are in the same segment (formally, when , or equivalently, ), then this leap step is called a simple leap step. If is in a later segment than (that is, when , which is equivalent to ) then this leap step is called an iterated leap step.

As all packets in the segment of containing have the same substitute packet , must be the heaviest packet in its segment. Furthermore, is not too light compared to the heaviest pending packet ; specifically, we have that . Indeed, as mentioned earlier, we have . It follows that , where the second inequality follows by the choice of in line 1 of Algorithm .

Figure 4.1: An illustration of the shift of packets in lines 6-11 in an iterated leap step. Each plan is depicted by a horizontal strip, divided into segments by vertical line segments at each tight slot. is the plan right after is scheduled and the current time is incremented to (but before packets released at time are taken ito account).

Slot-monotonicity. Our goal is to maintain the slot-monotonicity property, i.e., to ensure that for any fixed slot the value of does not decrease as the current time progresses from to . For this reason, we need to increase the weight of the substitute packet in each leap step (as ), which is done in line 4. (To maintain Assumption ii, we add an infinitesimal to the new weight of .) For the same reason, we also need to adjust the deadlines and weights of the packets , which is done in line 11. The deadlines of ’s are decreased to make sure that the segments between and do not merge (as merging could cause a decrease of some values of ). These deadline changes can be thought of as a sequence of substitutions, where replaces in the segment of ending at , replaces , etc., and finally, replaces in the segment ending at . We sometimes refer to this process as a “shift” of the ’s. See Figure 4.1 for an illustration. Then, if the weight of some is too low for its new segment, it is increased to match the earlier minimum of that segment, that is . (Again, to maintain Assumption ii, we add an infinitesimal to the new weight of .)

The changes in the plan after a leap step are elaborated in detail in Lemma A.5 in Appendix A.2. We summarize them here briefly. By the choice of , the definition of in line 9, and the while loop condition in line 7, we have that and that ’s deadline is in the segment of ending at , that is .

Let and let be the plan after is scheduled, the time is incremented to , and weights and deadlines are changed (according to lines 3-11 in the algorithm). Let be the plan after is scheduled and the time is incremented, but before the algorithm adjusts weights and deadlines. As discussed in Section 3, after from a later segment is scheduled (that is, in a leap step), the plan is , where . Observe that increasing the weight of a packet in the plan does not change the plan. Moreover, an analysis of the changes of values yields that decreasing the deadlines of (in line 11) does not change the plan, so we can conclude that holds, even in an iterated leap step.

The decrease of the deadlines ensures that any tight slot of is tight in as well. This property, together with the increase of the weights, allows us to prove that does not decrease for any even in a leap step. Formally, the slot-monotonicity property in the lemma below follows directly from Lemma A.2(c), Lemma A.3(c), and Lemma A.6 in Appendix A.2.

Lemma 4.1.

Let be the current plan in step just before an event of either arrival of a new packet or scheduling a packet (and incrementing the current time), and let be the plan after the event. Then for any , and also for in the case of packet arrival. Hence, in the computation of Algorithm PlanM, for any fixed , function is non-decreasing in as grows from to .

Comparison to previous algorithms. Our algorithm shares some broad features with known algorithms in the literature. Any online competitive algorithm needs to capture the tradeoff between weight and urgency when scheduling a packet, so some similarities between these algorithms are inevitable. As we found in our earlier attempts, however, the exact mechanism of formalizing this tradeoff is critical, and minor tweaks can dramatically affect the competitive ratio.

Some prior algorithms used the notion of optimal provisional schedules, which coincides with our concept of canonically ordered plans; recall that the plan is the maximum-weight feasible set of pending packets rather than their particular schedule. For example, the -competitive algorithm MG for instances with agreeable deadlines by Li et al. [17] (see also [19]) transmits packets from the plan only, either the heaviest packet or the earliest-deadline packet 222Strictly speaking, this is true for the simplified variant of MG [17], whereas the original MG transmitted either or another packet from the plan, sufficiently heavy compared to both and  [19].. The same authors [20] later designed a modified algorithm called DP (using memory) that achieves competitive ratio for arbitrary instances.

Our approach is similar to that of Englert and Westermann [14], who designed a -competitive memoryless algorithm and an improved -competitive variant with memory. Both their algorithms are based on the notion of suppressed packet supp(), for a packet in the plan , which, in our terminology, is the same as the substitute packet if is not in the initial segment. However, the two concepts differ for packets in the first segment. The memoryless algorithm in [14] identifies a packet of maximum “benefit”, which is measured by an appropriate linear combination of and , and sends either or (the earliest-deadline packet in the plan), based on the relation between and the benefit of . The algorithm with memory in [14] extends this approach by comparing ’s benefit to ’s “boosted weight” , where is the current step and is the maximum value of over . Thus, this algorithm uses memory to maintain the values of for all slots , using so-called levels.

Our algorithm involves several new ingredients that are critical to establishing competitive ratio . First, our analysis relies on full characterization of the evolution of the plan over time, in response to packet arrivals and scheduling events. This characterization is sketched in Section 3 and formally treated in Appendix A. Two, we introduce a new objective function for selecting a packet for scheduling. This function is based on a definition of substitute packets, , that accurately reflects the changes in the plan following scheduling events, including the case when is in the initial segment. Three, we introduce the concept of slot monotonicity, and devise a way for the algorithm to maintain it over time333 We remark that merely maintaining the value of in [14] does not prevent actual decreases of , which in turn affect the benefits of packets in the plan.. This property is very helpful in keeping track of the optimal profit. Last but not least, we introduce a novel potential function that captures the “advantage” of the algorithm over the adversary regarding future time steps.

5 Competitive Analysis

Let ALG be the schedule computed by Algorithm PlanM for an instance of PacketScheduling under consideration, and let OPT be a fixed optimal schedule for this instance (actually, OPT can be any schedule for this instance). For any time step , by and we will denote packets scheduled by ALG and OPT, respectively, in slot . Our overall goal is to show that . (Recall that denotes the original weight of packet .)

Notational convention. The plan changes in the course of the algorithm’s run, as a result of new packets arriving or scheduling a packet. In some contexts it is convenient to think of the current plan as a dynamic set, that we will denote by . When more formal treatment is needed, we will use letters , often with appropriate subscripts or superscripts, to denote the snapshot of the plan before or after a particular change. For clarity, we index the snapshots not by the current time, but by events. Recall that, as defined earlier in Section 3, an event is either the arrival of a new packet, or scheduling a packet in step (together with incrementing the current time to ). Events are numbered by integers, starting from 0, and each event occurs in a specific time step. Let denote the plan just before event . Thus, as a result of an event , the current plan changes from to .

Note that if is the scheduling event in step , then . This is a slight abuse of notation, but since we consistently use notation , etc. for time steps and , etc. for events, this notation will always have an unambiguous interpretation.

The same conventions apply to other sets used in the analysis: , , and , that we will define shortly. In general, we think about these sets as dynamic sets, denoted by calligraphic letters, that change over time, as new packets arrive and the algorithm schedules packets, and as we adjust the contents of these sets in the analysis. When necessary, we introduce notations for appropriate “snapshots” of these sets (using italic letters, typically with subscripts or superscripts), before and after the change under consideration.

5.1 Adversary Timetable and Shadow Packets

Adversary timetable. In our analysis we need a mechanism that would allow us to keep track of adversary’s future gain associated with the already released packets. A natural candidate for this mechanism would be the set of packets from OPT that have already been released but not yet scheduled. This simple definition, however, does not quite work for our purpose, partly because our amortized analysis involves making modifications to packets that are available for scheduling by the adversary.

The concept we use instead is called the adversary timetable and is denoted by . This is a dynamic set of packets (not necessarily from the original instance) that are scheduled in some slots in , where is the current time step. For , by we denote the packet scheduled in in slot . (Abusing notation, we will use to denote both the set of packets in the adversary timetable and their schedule.) Initially is empty, and later whenever a packet arrives and , then we add to to the slot in which is in OPT. When we analyze the scheduling event at a time step , we will remove from the packet that is scheduled in slot . (Naturally, then the adversary gains the weight of .) As hinted to earlier, in some situations we will also make other modifications of , including changing weights and deadlines of some packets. These changes will be described in detail in the analysis of packet scheduling events in Section 5.5.

Types of packets. Packets that are in the instance are referred to as original packets. (Virtual zero-weight packets from Assumption i are also original packets, as they are assumed to be part of the instance.) Original packets can get modified by the algorithm, and in the course of the analysis we can even insert ficticious packets (that are not in the instance) into the adversary timetable. The following terminology will be used:

Real packets are packets pending for the algorithm. They were earlier original packets but may have their weights or deadlines modified by the algorithm (in particular, original packets are also considered to be real packets). Each real packet pending at time has deadline and weight , which can change during the computation of the algorithm.

Shadow packets are packets created during the analysis. They are in essence just an accounting trick: they exist only in the adversary timetable (so they are not pending for the algorithm) and they represent deposits of profit, to be collected when the current time reaches the slot where they are scheduled in . The slot of where a shadow packet is scheduled never changes. For this reason we do not need to specify release times and deadlines of shadow packets, we do not include them in the canonical ordering, and we exempt them from assumption ii (so their weights need not be perturbed). Shadow packets are introduced in the analysis to ensure that certain invariants (to be defined shortly) are preserved during the computation.

Replacing packets. Modifications of the adversary timetable involve replacing some packets in by lighter or equal-weight packets, either real packets or shadow packets. As a result of such changes, at any time , even if , for some , contains a packet released at or before time , the packet in may be different.

Shadow packets are created in several cases of the analysis. For example, when the algorithm increases the weight of some (real) packet that is also in , then is replaced in by a shadow packet. When a shadow packet is created and added to its slot in it satisfies . From this time on it is tied to its slot and never changes. Therefore, by Lemma 4.1, its weight does not exceed , until it is eventually scheduled by the adversary when the current time reaches .

Replacement by real packets in may occur in an iterated leap step when, under some circumstances, we replace a packet by , which is always lighter than (see Lemma A.5(b)). When we make packet replacements we need to make sure that no packet in is scheduled after its current deadline, which requires care for packets whose deadlines were decreased. What will actually happen in the analysis of an iterated leap step is that in we replace packet either by a shadow packet or by . In the latter case, as the new deadline of is and as is added to the former slot of (which is at most ), we have that the slot of in will be before or at its new deadline.

We also need to be careful to avoid packet duplication in . It may happen, for example, that a real packet in whose deadline is decreased by the algorithm gets removed from (i.e., replaced by a shadow packet or by ), but re-inserted later into with its new weight in a different slot. As it was earlier removed, it is not considered to be duplicated in .

Adversary timetable invariant. Following our convention, denotes the adversary timetable just before event . The following invariant, that will be maintained throughout the analysis, captures properties of the packets in that will be crucial for our argument (see also Figure 5.1):

(InvA) For any event at time , the adversary timetable consists of two types of packets:

  • Packets in . These are real packets, as discussed above. Each such packet is in in a slot in interval .

  • Packets in . All these packets are shadow packets, with properties described above; in particular, each shadow packet is not pending for the algorithm and satisfies .

After each event , we change the adversary timetable so that invariant (InvA) is preserved, i.e., it holds for . For a shadow packet , we just need to ensure that when is created, since the value of does not decrease, by Lemma 4.1.

Figure 5.1: The sets of packets in the competitive analysis. Set of furloughed packets and backup plan are introduced in Section 5.2.

Amortized analysis. We bound the competitive ratio via amortized analysis, using a combination of three accounting techniques:

  • In leap steps, when the algorithm increases weights of some packets (the substitute packet and some ’s), we charge it a “penalty” equal to times the total weight increase.

  • We use a potential function, which quantifies the advantage of the algorithm over the adversary in future steps. This potential function is defined in Section 5.2.

  • As mentioned earlier, in some situations we replace packets in by lighter packets. If this happens, we add the appropriate “credit” (equal to the weight decrease) to the adversary’s gain in this step.

See Section 5.3 for a formal proof of -competitiveness of Algorithm PlanM using these three techniques.

5.2 Backup Plan and the Potential Function

In our analysis we will maintain a set of pending packets that we refer to as furloughed. Set consists mostly of some packets that were ousted from the plan, either as a result of arrivals of other packets or in a leap step. We maintain the invariant that no packet in is in the current plan , thus one can think of as a set of candidates for the substitute packet when the algorithm schedules a packet . Throughout the rest of the paper we will assume that contains sufficiently many packets with sufficiently large deadlines, for, whenever needed, we can simply add to such virtual packets with weight using assumption i. This convention will help us streamline the proofs.

Backup plan. We define the “backup plan” as . In other words, is obtained from by replacing the packets that are in by packets from . (Note that no packet in is in , which follows from invariant (InvA).)

According to our convention, we index snapshots of sets and by events, i.e., and represent sets and , respectively, just before event . We maintain the following invariant throughout the analysis:

(InvB) For any time and any event at time , the backup plan is a feasible set of pending packets.

Equivalently, invariant (InvB) ensures that for any slot it holds that . Similarly as for invariant (InvA), in the course of the analysis we make changes in the adversary schedule and set to preserve invariant (InvB). Note that the invariant guarantees that all packets in are pending. In particular, when maintaining the invariant after a scheduling event (when the algorithm schedules a packet and the time is incremented), we will remove from the expiring packet, if there is any.

We remark that may have a different structure than the current plan . The definitions of tight slots and segments extend to in a natural way, and they will be helpful in our proofs.

In the rest of this section we show a few lemmas that will be useful in showing that invariant (InvB) is preserved. We consider the state of the computation right before an event at a time . To avoid clutter we use simplified notations , , and for snapshots of the corresponding sets right before this event .

Lemma 5.1.

Consider the current plan , the backup plan , the set of furloughed packets, and the adversary timetable at time . Assume that invariant (InvB) holds and let be two time slots such that . Then

(5.1)
Proof.

By the definition of , we have and similarly with instead of . By canceling out the contribution of packets with deadline at most , we get . Since and , we obtain and the lemma follows. ∎

Lemma 5.2.

Consider the current plan , the backup plan , the set of furloughed packets, and the adversary timetable at time . Assume that invariant (InvB) holds and let be a tight slot of (possibly, ). Let be the earliest-deadline packet in with (by our convention, this exists) and let be the latest-deadline packet in with (undefined if there is none). Then:

  1. For any , it holds that .

  2. If is defined, then for any , it holds that . Otherwise, for any .

Proof.

We first observe that, since is feasible and is a tight slot for , we have .

(a) Let . By the definition of , there is no packet in with deadline in ; in particular . Using this, equation , and Lemma 5.1 (with and ), we obtain

which implies claim (a).

(b) If packet exists, let , otherwise let . Let . By the definition of , there is no packet in with deadline in , which implies that . Using this, equation , and Lemma 5.1 (with and ), we obtain

which implies claim (b). ∎

In some cases of the analysis we will have situations when a packet needs to be removed from . By the definiton of the backup plan, this causes to be added to , making infeasible. The lemma below shows that we can restore the feasibility of after such a change by removing a suitably chosen packet from .

Lemma 5.3.

Consider the current plan , the backup plan , the set of furloughed packets, and the adversary timetable at time . Assume that invariant (InvB) holds. Let (that is, is not in backup plan ), , and . Then

(i) , and

(ii) For any , set is feasible and (thus ).

Proof.

We use Lemma 5.1 with and as defined in the lemma. (Note that is well-defined, according to our convention that contains sufficiently many packets with sufficiently large deadlines.) From that lemma, we get . The existence of implies , and hence, holds as well, proving (i).

Pick any . From we obtain that is feasible. Inequality and imply that , and therefore , completing the proof of (ii). ∎

Potential function. We use the backup plan to define a potential function used in the amortized analysis of Algorithm PlanM. Formally, the potential just before event at time is the following:

(5.2)

The intuition behind this definition is as follows. In order to be -competitive, the average (per step) profit of Algorithm PlanM should be at least times the adversary’s average profit. However, due to the choice of coefficients in line 1 of the algorithm, Algorithm PlanM tends to postpone scheduling heavy packets with large deadlines. (For example, given just two packets, a tight packet with weight and a non-tight packet with weight , the algorithm will schedule the tight packet in the current step.) As a result, in tight instances, PlanM’s actual profit per step, throughout most of the game, is often smaller than times the adversary’s, and only near the end of the instance, when very heavy packets are scheduled, the algorithm will make up for this deficit.

In our amortized analysis, if there is a deficit in a given step, we pay for it with a “loan” that is represented by an appropriate increase of the potential function. Eventually, of course, these loans need to be repaid – the potential eventually decreases to and this decrease must be covered by excess profit. The formula for the potential is designed to guarantee such future excess profits. To see this, imagine that no more packets arrive. Since (by invariant (InvA) and ), the packets in will not be scheduled in the future by the adversary. On the other hand, intuitively, if the algorithm does not execute any more leap steps then it will collect the packets in , and if it does, it will collect some packets from (or better packets) after they will be added to the plan as substitute packets.

5.3 Overview of the Analysis

Initial and final state. At the beginning, per assumption i, we assume that the plan is pre-filled with virtual -weight packets, each in a slot equal to its deadline, and none of them scheduled by the adversary. Both set and the adversary timetable are empty i.e., , thus invariants (InvA) and (InvB) clearly hold, and . At the end, after all (non-virtual) packets expire, the potential equals as well.

Adversary gain. In each step , the adversary gain, denoted , is defined as the weight of packet that the adversary schedules in step , where is the index of the scheduling event in step , plus the credit (the difference between old and new weights) for replacing some packets in by lighter packets. Each packet is added to upon its arrival with its original weight (although in some cases it might immediately get replaced by a shadow packet), and the adversary gets the corresponding credit whenever the packet in is replaced by a lighter one, and also when packet is scheduled when the current time reaches . This implies that .

Amortized analysis. At the core of our analysis are bounds relating amortized gains of the algorithm and the adversary at each event . If is the index of a packet arrival event, then we will show the following packet-arrival inequality:

(5.3)

If is the index of the scheduling event in a step , then we will show that the following packet-scheduling inequality holds:

(5.4)

where is the packet in slot in the algorithm’s schedule ALG (thus is the algorithm’s gain), and is the total amount by which the algorithm increases the weights of its pending packets in step .

We prove the packet-arrival inequality in Section 5.4 and the packet-scheduling inequality in Section 5.5. Assuming that these two inequalities hold, we now show our main result.

Theorem 5.4.

Algorithm PlanM is -competitive.

Proof.

We show that , which implies the theorem. First, note that the sum of terms over all events equals , where is the initial potential and is the final potential after the last (scheduling) event . So