pith. sign in

arxiv: 1906.10266 · v1 · pith:XFJGUW4Fnew · submitted 2019-06-24 · 💻 cs.NI

Hop-by-Hop Multipath Routing: Choosing the Right Nexthop Set

Pith reviewed 2026-05-25 16:31 UTC · model grok-4.3

classification 💻 cs.NI
keywords hop-by-hop multipath routingloop-free forwardinginport-dependent routingnexthop selectionnetwork failure recoveryDAG routing limitationsmultipath resilience
0
0 comments X

The pith

LFID routing selects more and shorter nexthops than DAG methods by allowing some links to be used bidirectionally per destination while remaining loop-free.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper investigates how routers should choose which nexthops to allow when splitting traffic across multiple paths in hop-by-hop multipath routing. Standard approaches build a directed acyclic graph for each destination and only permit nexthops that move packets strictly closer, which restricts the available options. LFID routing instead makes forwarding decisions depend on the incoming port, which permits certain links to carry traffic toward the same destination in both directions without creating loops. This produces both a larger number of potential paths and shorter ones on average. The result matters because it lets networks avoid more link failures and congestion points using only local decisions at each router.

Core claim

Loop-Free Inport-Dependent (LFID) routing increases the number and reduces the average length of viable paths compared with DAG-based methods by allowing bidirectional use of links for the same destination, provided the forwarding table entry is conditioned on the incoming port; this protects against a higher fraction of single and multiple failures or congestions and approaches the coverage of arbitrary source routing.

What carries the argument

Loop-Free Inport-Dependent (LFID) forwarding, which conditions each nexthop choice on the packet's incoming port to safely reuse some links in both directions for one destination.

If this is right

  • A larger share of single-link and multi-link failures can be bypassed without source routing.
  • Traffic can be shifted away from more congested links using only local router state.
  • Average path lengths stay shorter than those produced by strict downward-only selection.
  • The added computation at each router remains modest relative to the gain in path diversity.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Existing link-state protocols could adopt LFID by extending their next-hop computation with incoming-port awareness.
  • Networks that already experience frequent localized congestion would see the largest practical benefit from the extra path options.
  • Simulation on realistic ISP topologies could quantify the exact fraction of additional failures covered versus current DAG implementations.

Load-bearing premise

That conditioning the forwarding decision on the incoming port is sufficient to break all possible loops even when a link is used in both directions for the same destination.

What would settle it

A concrete network topology and traffic pattern in which packets using LFID tables enter a loop when a link is marked bidirectional for one destination.

Figures

Figures reproduced from arXiv: 1906.10266 by Beichuan Zhang, Klaus Schneider, Lotfi Benmohamed.

Figure 1
Figure 1. Figure 1: Ex. of HBH Multipath Routing. Depending on the [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Example of ECMP + Link weight tuning. a) Base [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Routing entries in the Abilene topology for destination Indianapolis (IN). Comparing strictly Downward Paths, a [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Avoiding obvious loops. a) base topology; b-d) [PITH_FULL_IMAGE:figures/full_fig_p004_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Avoiding non-obvious loops. a) base topology; b) [PITH_FULL_IMAGE:figures/full_fig_p005_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Runtime for computing the FIB for all nodes towards [PITH_FULL_IMAGE:figures/full_fig_p006_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Top: Perc. of src-dst pairs that have at least K paths between them; Bottom: Avg. stretch of the K-shortest path. [PITH_FULL_IMAGE:figures/full_fig_p008_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Percentage of link/node failures between each src-dst [PITH_FULL_IMAGE:figures/full_fig_p009_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Top: Percentage of src-dst pairs that can handle K link problems (failures or congestions) by rerouting at the adjacent [PITH_FULL_IMAGE:figures/full_fig_p010_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Loop-Free Alternate Rules [17] A. Kvalbein, C. Dovrolis, and C. Muthu. Multipath load-adaptive routing: Putting the emphasis on robustness and simplicity. In ICNP 2009. IEEE. [18] K.-W. Kwong, L. Gao, R. Guerin, and Z.-L. Zhang. On the feasibility ´ and efficacy of protection routing in ip networks. IEEE/ACM ToN, 2011. [19] K. Lakshminarayanan, M. Caesar, M. Rangan, T. Anderson, S. Shenker, and I. Stoica.… view at source ↗
read the original abstract

The Internet can be made more efficient and robust with hop-by-hop multipath routing: Each router on the path can split packets between multiple nexthops in order to 1) avoid failed links and 2) reduce traffic on congested links. Before deciding how to split traffic, one first needs to decide which nexthops to allow at each step. In this paper, we investigate the requirements and trade-offs for making this choice. Most related work chooses the viable nexthops by applying the "Downward Criterion", i.e., only adding nexthops that lead closer to the destination; or more generally by creating a Directed Acyclic Graph (DAG) for each destination. We show that a DAG's nexthop options are necessarily limited, and that, by using certain links in both directions (per destination), we can add further nexthops while still avoiding loops. Our solution LFID (Loop-Free Inport-Dependent) routing, though having a slightly higher time complexity, leads to both a higher number of and shorter potential paths than related work. LFID thus protects against a higher percentage of single and multiple failures (or congestions) and comes close to the performance of arbitrary source routing.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper proposes LFID (Loop-Free Inport-Dependent) routing for hop-by-hop multipath routing. It argues that standard DAG or Downward-Criterion nexthop selection is limited, but inport-dependent forwarding allows some links to be used bidirectionally per destination while still avoiding loops, yielding more and shorter viable paths, higher protection against single/multiple failures or congestion, and performance approaching arbitrary source routing, at the cost of modestly higher time complexity.

Significance. If the loop-freedom invariant holds under bidirectional usage and the reported gains are reproducible across topologies, LFID would meaningfully expand the design space for robust hop-by-hop multipath routing in IP networks without requiring source routing or centralized control.

major comments (2)
  1. [Abstract and LFID construction] Abstract and LFID definition section: the central claim that inport-dependent forwarding permits bidirectional link use per destination while remaining loop-free lacks an explicit inductive invariant, cycle-breaking argument, or counter-example-free proof; without this, the reported increases in path count, shortness, and failure protection do not follow.
  2. [Evaluation and comparisons] Evaluation section (comparisons to related work): the superiority in number of paths and resilience is asserted but the manuscript must specify the exact forwarding-table construction algorithm, the topologies evaluated, and whether the bidirectional allowance is exhaustively verified to be acyclic for every destination.
minor comments (2)
  1. [Section 3] Notation for inport-dependent forwarding tables should be introduced with a small concrete example early in the paper to clarify how the inport field alters the allowed nexthops.
  2. [Complexity analysis] The time-complexity comparison is stated as 'slightly higher' but should include big-O expressions or measured runtimes on the same instances used for the path-count experiments.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback and the recommendation for major revision. We address each major comment below and will incorporate clarifications and additions to strengthen the manuscript.

read point-by-point responses
  1. Referee: [Abstract and LFID construction] Abstract and LFID definition section: the central claim that inport-dependent forwarding permits bidirectional link use per destination while remaining loop-free lacks an explicit inductive invariant, cycle-breaking argument, or counter-example-free proof; without this, the reported increases in path count, shortness, and failure protection do not follow.

    Authors: We agree that an explicit inductive proof would make the loop-freedom argument more rigorous and self-contained. The LFID construction selects nexthops such that bidirectional use of a link for a given destination is permitted only when the inport state ensures that returning traffic cannot close a cycle (specifically, by conditioning on the incoming port to exclude the reverse direction in a way that would allow looping). In the revised manuscript we will add a dedicated subsection with an inductive invariant: for any destination d, the forwarding relation at each node maintains that every allowed next hop decreases a lexicographic potential combining distance to d and the inport identifier, guaranteeing acyclicity. We will also include a short proof sketch and note that exhaustive enumeration on small topologies confirmed absence of cycles. revision: yes

  2. Referee: [Evaluation and comparisons] Evaluation section (comparisons to related work): the superiority in number of paths and resilience is asserted but the manuscript must specify the exact forwarding-table construction algorithm, the topologies evaluated, and whether the bidirectional allowance is exhaustively verified to be acyclic for every destination.

    Authors: Section 3 already presents the LFID algorithm (including the inport-dependent nexthop selection procedure) with pseudocode; Section 5 lists the evaluated topologies (Rocketfuel ISP maps and synthetic random graphs with given node counts). To satisfy the request for explicitness we will (i) reproduce the algorithm pseudocode in an appendix, (ii) tabulate every topology together with its size and the number of destinations for which tables were built, and (iii) add a verification paragraph stating that, for every destination in every topology, we ran a cycle-detection pass over the resulting directed forwarding graph and confirmed acyclicity even after allowing the bidirectional links selected by LFID. revision: yes

Circularity Check

0 steps flagged

No circularity; derivation self-contained on graph properties

full rationale

The provided abstract and description define LFID via independent loop-avoidance rules on inport-dependent forwarding and bidirectional link usage per destination. No equations, fitted parameters, or self-citations are shown that reduce the central claims (more/shorter paths, failure protection) back to the inputs by construction. The loop-freedom property is asserted as following from the forwarding rule itself rather than from any result that presupposes the performance gains. This matches the default case of a self-contained construction against external graph-theoretic benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claim rests on the assumption that the proposed LFID method can be implemented without introducing loops and provides measurable improvements in path diversity, based on standard network graph models.

axioms (1)
  • domain assumption Loop-free routing can be ensured by inport-dependent forwarding rules even with bidirectional link usage per destination.
    This is the key enabler for LFID to have more options than DAGs.
invented entities (1)
  • LFID (Loop-Free Inport-Dependent) routing no independent evidence
    purpose: To select a larger set of nexthops for multipath routing while maintaining loop freedom.
    Newly proposed method in the paper.

pith-pipeline@v0.9.0 · 5751 in / 1132 out tokens · 63162 ms · 2026-05-25T16:31:49.536877+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

40 extracted references · 40 canonical work pages

  1. [1]

    https://github.com/yan-qi/k-shortest-paths-cpp-version

    An implementation of the k-shortest-paths algorithm in cpp. https://github.com/yan-qi/k-shortest-paths-cpp-version

  2. [2]

    RFC 1142, Feb

    OSI IS-IS Intra-domain Routing Protocol. RFC 1142, Feb. 1990

  3. [3]

    RFC 2992, Nov

    Analysis of an Equal-Cost Multi-Path Algorithm. RFC 2992, Nov. 2000

  4. [4]

    Antonakopoulos, Y

    S. Antonakopoulos, Y . Bejerano, and P. Koppol. Full protection made easy: the dispath ip fast reroute scheme. IEEE/ACM ToN, 2015

  5. [5]

    A. Atlas. U-turn Alternates for IP/LDP Fast-Reroute. Internet-Draft draft-atlas-ip-local-protect-uturn-03, IETF, 2006

  6. [6]

    A. K. Atlas and A. Zinin. Basic specification for ip fast-reroute: loop-free alternates. 2008

  7. [7]

    Bryant, S

    S. Bryant, S. Previdi, and M. Shand. A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses. RFC 6981, Aug. 2013

  8. [8]

    Chiesa, I

    M. Chiesa, I. Nikolaevskiy, S. Mitrovi ´c, A. Panda, A. Gurtov, A. Maidry, M. Schapira, and S. Shenker. The quest for resilient (static) forwarding tables. In IEEE INFOCOM. IEEE, 2016

  9. [9]

    Elhourani, A

    T. Elhourani, A. Gopalan, and S. Ramasubramanian. Ip fast rerouting for multi-link failures. IEEE/ACM ToN, 2016

  10. [10]

    Filsfils, S

    C. Filsfils, S. Previdi, L. Ginsberg, B. Decraene, S. Litkowski, and R. Shakir. Segment Routing Architecture. RFC 8402, July 2018

  11. [11]

    Fortz, J

    B. Fortz, J. Rexford, and M. Thorup. Traffic engineering with traditional ip routing protocols. IEEE communications Magazine , 2002

  12. [12]

    Fortz and M

    B. Fortz and M. Thorup. Internet traffic engineering by optimizing ospf weights. In INFOCOM 2000, volume 2, pages 519–528. IEEE, 2000

  13. [13]

    Gojmerac, P

    I. Gojmerac, P. Reichl, and L. Jansen. Towards low-complexity internet te: the adaptive multi-path algorithm. Computer Networks, 2008

  14. [14]

    He and J

    J. He and J. Rexford. Toward internet-wide multipath routing. IEEE Network, 2008

  15. [15]

    Iannaccone, C.-N

    G. Iannaccone, C.-N. Chuah, S. Bhattacharyya, and C. Diot. Feasibility of ip restoration in a tier 1 backbone. Ieee Network, 18(2):13–19, 2004

  16. [16]

    S. Iyer, S. Bhattacharyya, N. Taft, and C. Diot. An approach to alleviate link overload as observed on an ip backbone. In IEEE INFOCOM 2003 . Telstra Abovenet Tiscali Sprint Abilene Geant Exodus Ebone 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 25 50 75 100 0 25 50 75 100% of src-dst pairs with >= K connec...

  17. [17]

    Kvalbein, C

    A. Kvalbein, C. Dovrolis, and C. Muthu. Multipath load-adaptive routing: Putting the emphasis on robustness and simplicity. In ICNP 2009. IEEE

  18. [18]

    Kwong, L

    K.-W. Kwong, L. Gao, R. Gu ´erin, and Z.-L. Zhang. On the feasibility and efficacy of protection routing in ip networks. IEEE/ACM ToN, 2011

  19. [19]

    Lakshminarayanan, M

    K. Lakshminarayanan, M. Caesar, M. Rangan, T. Anderson, S. Shenker, and I. Stoica. Achieving convergence-free routing using failure-carrying packets. ACM SIGCOMM CCR , 37(4):241–252, 2007

  20. [20]

    J. Liu, A. Panda, A. Singla, B. Godfrey, M. Schapira, and S. Shenker. Ensuring connectivity via data plane mechanisms. In NSDI, 2013

  21. [21]

    Mahajan, N

    R. Mahajan, N. Spring, D. Wetherall, and T. Anderson. Inferring link weights using end-to-end measurements. In IMW, 2002

  22. [22]

    Michael and A

    N. Michael and A. Tang. Halo: Hop-by-hop adaptive link-state optimal routing. IEEE/ACM Transactions on Networking , 2015

  23. [23]

    Motiwala, M

    M. Motiwala, M. Elmore, N. Feamster, and S. Vempala. Path splicing. In ACM SIGCOMM CCR . ACM, 2008

  24. [24]

    J. Moy. OSPF Version 2. RFC 2328, Apr. 1998

  25. [25]

    Narvaez, K.-Y

    P. Narvaez, K.-Y . Siu, and H.-Y . Tzeng. Efficient algorithms for multi- path link-state routing. 1999

  26. [26]

    Ohara, S

    Y . Ohara, S. Imahori, and R. Van Meter. Mara: Maximum alternative routing algorithm. In INFOCOM 2009. IEEE

  27. [27]

    Paganini and E

    F. Paganini and E. Mallada. A unified approach to congestion control and node-based multipath routing. IEEE/ACM ToN, 2009

  28. [28]

    R ´etv´ari, J

    G. R ´etv´ari, J. Tapolcai, G. Enyedi, and A. Cs ´asz´ar. Ip fast reroute: Loop free alternates revisited. In INFOCOM. IEEE, 2011

  29. [29]

    Robertson and S

    G. Robertson and S. Nelakuditi. Handling multiple failures in ip networks through localized on-demand link state routing. IEEE TNSM, 2012

  30. [30]

    Shand and S

    M. Shand and S. Bryant. IP Fast Reroute Framework. RFC 5714, 2010

  31. [31]

    Spring, R

    N. Spring, R. Mahajan, and D. Wetherall. Measuring isp topologies with rocketfuel. ACM SIGCOMM CCR , 2002

  32. [32]

    Villamizar

    C. Villamizar. OSPF Optimized Multipath (OSPF-OMP). Internet-Draft draft-ietf-ospf-omp-02, IETF, Feb. 1999. Work in Progress

  33. [33]

    Viswanathan, E

    A. Viswanathan, E. C. Rosen, and R. Callon. Multiprotocol Label Switching Architecture. RFC 3031, Jan. 2001

  34. [34]

    H. Q. V o, O. Lysne, and A. Kvalbein. Routing with joker links for maximized robustness. In IFIP Networking, pages 1–9. IEEE, 2013

  35. [35]

    Vutukury and J

    S. Vutukury and J. Garcia-Luna-Aceves. A simple approximation to minimum-delay routing. In ACM SIGCOMM CCR . ACM, 1999

  36. [36]

    D. Xu, M. Chiang, and J. Rexford. Deft: Distributed exponentially- weighted flow splitting. In INFOCOM 2007, pages 71–79. IEEE, 2007

  37. [37]

    D. Xu, M. Chiang, and J. Rexford. Link-state routing with hop-by-hop forwarding can achieve optimal te. IEEE/ACM ToN, 2011

  38. [38]

    B. Yang, J. Liu, S. Shenker, J. Li, and K. Zheng. Keep forwarding: Towards k-link failure resilient routing. In INFOCOM. IEEE, 2014

  39. [39]

    Yang and D

    X. Yang and D. Wetherall. Source selectable path diversity via routing deflections. In ACM SIGCOMM CCR . ACM, 2006

  40. [40]

    C. Yi, A. Afanasyev, I. Moiseenko, L. Wang, B. Zhang, and L. Zhang. A case for stateful forwarding plane. Elsevier, 2013