Table of Contents
Fetching ...

An Optimal $3$-Fault-Tolerant Connectivity Oracle

Evangelos Kosinas

TL;DR

We present an optimal DFS-based connectivity oracle for undirected graphs that withstands up to three vertex failures. The method preprocesses in $O(n+m)$ time, uses $O(n)$ space, and answers, in $O(1)$ time, queries about whether two vertices remain connected after removing any set $F$ with $|F|\le 3$. Central to the approach is a DFS-tree framework that avoids compact vertex-cut representations, instead leveraging internal components, hanging subtrees, and a connectivity graph $\mathcal{R}$ to capture inter-component connectivity; this yields not only fast queries but also efficient extensions to count the number of components and to perform related vertex-cut queries. The work integrates with the Kosinas DFS-based framework and offers a path toward optimal solutions for higher vertex-failure counts, providing insights and tools (low/high points, left/right skipping points, and batch-even processing via permutations) that may generalize beyond $d_\star=3$.

Abstract

We present an optimal oracle for answering connectivity queries in undirected graphs in the presence of at most three vertex failures. Specifically, we show that we can process a graph $G$ in $O(n+m)$ time, in order to build a data structure that occupies $O(n)$ space, which can be used in order to answer queries of the form "given a set $F$ of at most three vertices, and two vertices $x$ and $y$ not in $F$, are $x$ and $y$ connected in $G\setminus F$?" in constant time, where $n$ and $m$ denote the number of vertices and edges, respectively, of $G$. The idea is to rely on the DFS-based framework introduced by Kosinas [ESA'23], for handling connectivity queries in the presence of multiple vertex failures. Our technical contribution is to show how to appropriately extend the toolkit of the DFS-based parameters, in order to optimally handle up to three vertex failures. Our approach has the interesting property that it does not rely on a compact representation of vertex cuts, and has the potential to provide optimal solutions for more vertex failures. Furthermore, we show that the DFS-based framework can be easily extended in order to answer vertex-cut queries, and the number of connected components in the presence of multiple vertex failures. In the case of three vertex failures, we can answer such queries in $O(\log n)$ time.

An Optimal $3$-Fault-Tolerant Connectivity Oracle

TL;DR

We present an optimal DFS-based connectivity oracle for undirected graphs that withstands up to three vertex failures. The method preprocesses in time, uses space, and answers, in time, queries about whether two vertices remain connected after removing any set with . Central to the approach is a DFS-tree framework that avoids compact vertex-cut representations, instead leveraging internal components, hanging subtrees, and a connectivity graph to capture inter-component connectivity; this yields not only fast queries but also efficient extensions to count the number of components and to perform related vertex-cut queries. The work integrates with the Kosinas DFS-based framework and offers a path toward optimal solutions for higher vertex-failure counts, providing insights and tools (low/high points, left/right skipping points, and batch-even processing via permutations) that may generalize beyond .

Abstract

We present an optimal oracle for answering connectivity queries in undirected graphs in the presence of at most three vertex failures. Specifically, we show that we can process a graph in time, in order to build a data structure that occupies space, which can be used in order to answer queries of the form "given a set of at most three vertices, and two vertices and not in , are and connected in ?" in constant time, where and denote the number of vertices and edges, respectively, of . The idea is to rely on the DFS-based framework introduced by Kosinas [ESA'23], for handling connectivity queries in the presence of multiple vertex failures. Our technical contribution is to show how to appropriately extend the toolkit of the DFS-based parameters, in order to optimally handle up to three vertex failures. Our approach has the interesting property that it does not rely on a compact representation of vertex cuts, and has the potential to provide optimal solutions for more vertex failures. Furthermore, we show that the DFS-based framework can be easily extended in order to answer vertex-cut queries, and the number of connected components in the presence of multiple vertex failures. In the case of three vertex failures, we can answer such queries in time.

Paper Structure

This paper contains 56 sections, 19 theorems, 18 figures, 3 tables, 7 algorithms.

Key Result

Theorem 1.1

We can process an undirected graph $G$ with $n$ vertices and $m$ edges in $O(n+m)$ time, in order to build a data structure with $O(n)$ size, which can answer queries of the form "given a set $F$ of at most three vertices, and two vertices $x$ and $y$ not in $F$, are $x$ and $y$ connected in $G\setm

Figures (18)

  • Figure 1: An example of internal components (in gray) and hanging subtrees (in blue) of a DFS tree rooted at $r$, given a set of vertices that have failed to work. (The failed vertices are coloured red.) We have that $T(c)$ is a hanging subtree of the failed vertex $f$, and $T(c')$ is a hanging subtree of $f'$. Notice that there two kinds of back-edges that remain in the graph: those that connect internal components, and those that connect hanging subtrees and internal components. (There is no direct connection between two hanging subtrees with a back-edge.) We have that $C_3$ remains connected with $C_1$ directly with a back-edge, and $C_1$ remains connected with $C_2$ through the mediation of the hanging subtree $T(c)$.
  • Figure 2: The vertices $\{v_1,v_2,v_3,v_4\}$ have failed to work. $T(c_1)$ is an isolated hanging subtree of $v_2$, because it has no surviving back-edges. On the other hand, $T(c_2)$ is not an isolated hanging subtree of $v_2$, because it has a surviving back-edge whose lower endpoint is not a failed vertex. $T(c_3)$ is not a hanging subtree of $v_2$, because there are descendants of $c_3$ that are failed vertices. $T(c_4)$ is an isolated hanging subtree of $v_3$, because the lower endpoint of its only surviving back-edge is $v_2$. $T(c_5)$ is an isolated hanging subtree of $v_4$, because the lower endpoints of its two surviving back-edges are $v_1$ and $v_3$. $T(c_6)$ is a non-isolated hanging subtree of $v_4$, because it has a surviving back-edge whose lower endpoint is not a failed vertex. Following the notation in the main text, and assuming that we store up to four surviving back-edges, we have the sorted lists $\mathcal{L}(c_1)=\{\bot,\bot,\bot,\bot\}$, $\mathcal{L}(c_2)=\{y,\bot,\bot,\bot\}$, $\mathcal{L}(c_3)=\{v_1,\bot,\bot,\bot\}$, $\mathcal{L}(c_4)=\{v_2,\bot,\bot,\bot,\}$, $\mathcal{L}(c_5)=\{v_1,v_3,\bot,\bot\}$, and $\mathcal{L}(c_6)=\{v_3,z,\bot,\bot\}$.
  • Figure 3: The result of adding an auxiliary root $r$ to the DFS tree $T_0$, and splitting the edges of the graph. The original vertices of the graph are coloured white. The artificial root, and the artificial vertices that split the tree-edges are coloured black. The children of the ordinary vertices that split the back-edges that stem from them are coloured yellow.
  • Figure 4: An illustration of the situation analyzed in Lemma \ref{['lemma:lbelowwonT_high_MAIN']}. The set of failed vertices is $\{v,p(c)\}$, and the goal is to check whether the parts $A$ and $B$ remain connected. To do this, we rely on the leftmost and the rightmost points, $L_p(c)$ and $R_p(c)$, respectively, that provide back-edges from $T(c)$ to $T[p(p(c)),r]$.
  • Figure 5: The four possibilities for the ancestry relation between the vertices from $F$, when $|F|=3$.
  • ...and 13 more figures

Theorems & Definitions (33)

  • Theorem 1.1
  • Theorem 1.2
  • Corollary 1.3
  • Corollary 1.4
  • Corollary 1.5
  • Lemma 2.1: Implicit in DBLP:conf/esa/Kosinas23
  • Lemma 3.3
  • Remark 3.4
  • proof
  • Proposition 4.1
  • ...and 23 more