Table of Contents
Fetching ...

List Update with Delays or Time Windows

Yossi Azar, Shahar Lewkowicz, Danny Vainstein

TL;DR

This work extends the classical List Update problem by introducing List Update with Time Windows and List Update with Delays, where requests arrive with deadlines or delay functions and multiple requests can be served concurrently. The authors design online algorithms that remain constant-competitive in non-clairvoyant settings, achieving a $24$-competitive ratio for Time Windows and a $336$-competitive ratio for Delays, respectively. The key methodological advance is the construction of novel potential functions that manage the inherent time-discrepancies between the online algorithm and the optimal offline solution, along with trigger-based, event-driven strategies for serving requests and reorganizing the list. The results illustrate that adding deadline-based flexibility or delay penalties can still permit strong online performance guarantees, and they open avenues for further improvements, including potential randomized or clairvoyant enhancements and tighter bounds.

Abstract

We consider the problem of List Update, one of the most fundamental problems in online algorithms. We are given a list of elements and requests for these elements that arrive over time. Our goal is to serve these requests, at a cost equivalent to their position in the list, with the option of moving them towards the head of the list. Sleator and Tarjan introduced the famous "Move to Front" algorithm (wherein any requested element is immediately moved to the head of the list) and showed that it is 2-competitive. While this bound is excellent, the absolute cost of the algorithm's solution may be very large (e.g., requesting the last half elements of the list would result in a solution cost that is quadratic in the length of the list). Thus, we consider the more general problem wherein every request arrives with a deadline and must be served, not immediately, but rather before the deadline. We further allow the algorithm to serve multiple requests simultaneously. We denote this problem as List Update with Time Windows. While this generalization benefits from lower solution costs, it requires new types of algorithms. In particular, for the simple example of requesting the last half elements of the list with overlapping time windows, Move-to-Front fails. We show an O(1) competitive algorithm. The algorithm is natural but the analysis is a bit complicated and a novel potential function is required. Thereafter we consider the more general problem of List Update with Delays in which the deadlines are replaced with arbitrary delay functions. This problem includes as a special case the prize collecting version in which a request might not be served (up to some deadline) and instead suffers an arbitrary given penalty. Here we also establish an O(1) competitive algorithm for general delays. The algorithm for the delay version is more complex and its analysis is significantly more involved.

List Update with Delays or Time Windows

TL;DR

This work extends the classical List Update problem by introducing List Update with Time Windows and List Update with Delays, where requests arrive with deadlines or delay functions and multiple requests can be served concurrently. The authors design online algorithms that remain constant-competitive in non-clairvoyant settings, achieving a -competitive ratio for Time Windows and a -competitive ratio for Delays, respectively. The key methodological advance is the construction of novel potential functions that manage the inherent time-discrepancies between the online algorithm and the optimal offline solution, along with trigger-based, event-driven strategies for serving requests and reorganizing the list. The results illustrate that adding deadline-based flexibility or delay penalties can still permit strong online performance guarantees, and they open avenues for further improvements, including potential randomized or clairvoyant enhancements and tighter bounds.

Abstract

We consider the problem of List Update, one of the most fundamental problems in online algorithms. We are given a list of elements and requests for these elements that arrive over time. Our goal is to serve these requests, at a cost equivalent to their position in the list, with the option of moving them towards the head of the list. Sleator and Tarjan introduced the famous "Move to Front" algorithm (wherein any requested element is immediately moved to the head of the list) and showed that it is 2-competitive. While this bound is excellent, the absolute cost of the algorithm's solution may be very large (e.g., requesting the last half elements of the list would result in a solution cost that is quadratic in the length of the list). Thus, we consider the more general problem wherein every request arrives with a deadline and must be served, not immediately, but rather before the deadline. We further allow the algorithm to serve multiple requests simultaneously. We denote this problem as List Update with Time Windows. While this generalization benefits from lower solution costs, it requires new types of algorithms. In particular, for the simple example of requesting the last half elements of the list with overlapping time windows, Move-to-Front fails. We show an O(1) competitive algorithm. The algorithm is natural but the analysis is a bit complicated and a novel potential function is required. Thereafter we consider the more general problem of List Update with Delays in which the deadlines are replaced with arbitrary delay functions. This problem includes as a special case the prize collecting version in which a request might not be served (up to some deadline) and instead suffers an arbitrary given penalty. Here we also establish an O(1) competitive algorithm for general delays. The algorithm for the delay version is more complex and its analysis is significantly more involved.
Paper Structure (14 sections, 27 theorems, 34 equations, 5 figures, 2 algorithms)

This paper contains 14 sections, 27 theorems, 34 equations, 5 figures, 2 algorithms.

Key Result

Theorem 3.2

For each sequence of requests $\sigma$, we have that

Figures (5)

  • Figure 1: An example of $ALG$'s behavior compared to $OPT$'s behavior on a sequence $\sigma$ during the time horizon. The horizontal lines are the time horizon of $ALG$ and $OPT$ running on $\sigma$. For each request (trigger) in $\sigma$ - there is a dot in the top horizontal line at the time $ALG$ served this request which is its deadline (Corollary \ref{['deadlines.lemma.3']}). Therefore, the requests (dots) in the top horizontal line are ordered according to their deadlines (which may be different from their arrival times order). The dots in the bottom line are at times when $OPT$ served requests. For each request (trigger) in $\sigma$ there is a non-horizontal segment between the time when $ALG$ served this request and the time when $OPT$ served this request. $OPT$ served first the 3 red dot requests (together), then the 4 gre'en dot requests (together) and then the blue dot request. By Lemma \ref{['deadlines.lemma.1']}, each monochromatic requests are served by $OPT$ at their minimum deadline. Denote by $b_k$ the position of the requested element in $ALG$'s list. By Lemma \ref{['deadlines.lemma.8']} we have $4b_1\leq 2b_2\leq b_8$ and $8b_3\leq 4b_4 \leq 2b_6 \leq b_7$. By Lemma \ref{['deadlines.lemma.17']} we have that $8b_5\leq 4b_6 \leq 2b_7 \leq b_8$ since the 4 rightmost dots requests in the top horizontal line were active in $ALG$ at the deadline of the blue request.
  • Figure 2: The graphs of $\psi(x,2)$ (in blue and purple), $\psi(x,3)$ (in red and purple) and the function $7x$.
  • Figure 3: The usage of Lemma \ref{['deadline.lemma.24']} and Lemma \ref{['deadlines.lemma.14']}.
  • Figure 4: An example of a sequence of requests. For each $1\leq i\leq 5$, we see the time windows of the requests for the element $c_i$ during the time horizon. Each request is represented by a segment which is the request's time window. At time $t=t_0$ (which is represented by a vertical red line) - an algorithm may serve requests for the elements $c_1$, $c_2$, $c_3$ and $c_5$ together: these requests are blue in this figure. One of these requests (the request for the element $c_1$) just reached its deadline at time $t_0$, i.e. its time window ends. Another request (a request for the element $c_2$) just arrived at time $t_0$, i.e. its time window begins. Note that, as seen in the example, we may have multiple requests on a single element at a given moment.
  • Figure 5: Another example of $ALG$'s behavior compared to $OPT$'s behavior on a sequence $\sigma$ where $OPT$ served all of them together, this time the time windows of the requests also appear. The trigger requests $r_1$, $r_2$ and $r_3$ were served separately by $ALG$: the top list is $ALG$'s list before $ALG$ served these requests, the middle list is $ALG$'s list after $ALG$ served these requests. We have $x_1=2,x_2=10,x_3=5$. At time $q_1$, $ALG$ served $r_1$: it paid an access cost of $3$ and a swapping cost of $1$ for moving $e_1$ to the beginning of its list. Then, at time $q_3$, $ALG$ served $r_3$: it paid an access cost of $9$ and a swapping cost of $4$ for moving $e_3$ to the beginning of its list. Then, at time $q_2$, $ALG$ served $r_2$: it paid an access cost of $12$ and a swapping cost of $9$ for moving $e_2$ to the beginning of its list. Therefore we have $A(\sigma)=3+1+9+4+12+9=38$. The bottom list is $OPT$'s list. We assume that $OPT$ served the $3$ requests together without performing any swaps. Due to Lemma \ref{['deadlines.lemma.1']}, we have that $OPT$ served these requests at time $q_1$, which is the earliest deadline of the requests. Therefore, we have that $T_{OPT}=\{q_1\}$ and $R^{OPT}_{q_1}=\{1,2,3\}=\{k^{q_1}_1,k^{q_1}_2,k^{q_1}_3\}$ where $k^{q_1}_1=1,k^{q_1}_2=3,k^{q_1}_3=2$. We have $y_1=4,y_2=3,y_3=1$. Therefore we have $J(q_1)=1$ and $z_1=z_2=z_3=y_1=4$. We have $OPT(\sigma)=y_{J(q_1)}=4$.

Theorems & Definitions (55)

  • Definition 2.1
  • Definition 3.1
  • Theorem 3.2
  • Theorem 4.1
  • Definition 5.1
  • Definition 5.2
  • Definition 5.3
  • Definition 5.4
  • Definition 5.5
  • Definition 5.6
  • ...and 45 more