{"id":"585b9608-05e9-4f74-ab1c-f013bea31da0","arxiv_id":"2608.06101","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"A UDP overlay that combines tier-synchronized path discovery with coupled consumer/forwarder congestion control can safely expand usable WAN multipath diversity and reduce tail FCT by up to 81.5% over ECMP-limited baselines.","lead":"MARS is a receiver-driven multipath transport that runs as a UDP overlay, letting cooperating forwarders discover additional paths without changing IP routing. In simulations and Mininet emulation it cut worst-case flow completion times by up to 81.5% versus ECMP-limited baselines when overlay forwarders cooperated, while endpoint-only deployment stayed competitive.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Safety of tier-synchronized probing is not established: Algorithm 5 advances ProbeIdx after a single TierConv Data, so a lost/delayed tier member can trigger premature tier advancement and invalidate the loop-freedom claim.","rationale":"The reader's verdict is CONDITIONAL, and the reader's weakest assumption is the tier-synchronization safety property. I agree and sharpen it to a concrete algorithmic gap: the consumer does not wait for all tier members, only one Data packet. This is load-bearing because the entire benefit over PCON/ECMP is attributed to safe path expansion; if the invariant fails, MARS can exhibit the same looped-interest pathologies as PCON. The loss/failure experiments in Section V-D do not include a scenario that isolates this interleaving, and the paper explicitly defers formal guarantees (Appendix D provides pseudocode, not a proof). I do not think the paper should be rejected; the design is plausible, the evaluation is controlled, and the oracle baselines are a thoughtful control. But acceptance should remain conditional on validating this invariant (or proving it), which is exactly the reader's position. The lack of confidence intervals and the acknowledged MPQUIC baseline handicap are secondary and would not change the verdict.","tokens_in":19086,"tokens_out":8093,"duration_ms":68483,"concrete_test":"Extend the existing Mininet prototype to log, per forwarder, the ProbeIdx at which it leaves each tier, and to record every ValidUpstream face used by data Interests. Run a topology with at least two forwarders in the same tier and inject 1% random loss on PD Data packets (and, as a separate deterministic test, delay the TierConv Data from one tier member until after the consumer has already observed TierConv from another). Check the invariant that all tier members receive ProbeIdx k only after all have reported TierConv for k-1; if any Interest traverses a face whose hop-count distance is not strictly decreasing, or revisits a node, the safety claim is refuted. Repeat 10 runs; a clean result would support the reader's conditional acceptance.","verdict_should_be":"UNCHANGED","load_bearing_attack":"MARS's central claim is that tier-synchronized path discovery safely expands forwarding opportunities beyond ECMP while avoiding looped Interests, backward steering, and path inflation. This depends on the invariant that a forwarder begins probing tier t+1 only after all nodes in tier t have converged. The paper states this invariant (Section III-B2) but the pseudocode does not enforce it. Algorithm 5 (Consumer-Driven Synchronization) allocates a new ProbeIdx as soon as one received Data has TierConv=true (line 6), with no accumulation of convergence across all tier members. If a TierConv Data from another member of the same tier is lost or delayed, the consumer advances; the lagging forwarder then receives the higher ProbeIdx and, via SYNCPROBEIDX (Algorithm 5 lines 13–15), probes its next tier before completing the current one. The local removal of the downstream ingress face (Algorithm 2 line 4) cannot repair a cross-node violation, and the hop-count threshold is only applied at initial grouping (Algorithm 3). Thus loop-free and backward-steering-free operation under loss/asynchrony is not actually proven, and the 81.5% FCT reduction depends on that safety property. This is a correctness gap, not a style issue; the paper's own Appendix A shows the pathologies that appear when this invariant fails.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents MARS, a receiver-driven, forwarder-assisted multipath transport for WAN environments, built as an ICN-style UDP overlay. MARS combines tier-synchronized path discovery with coupled consumer/forwarder congestion control, and is evaluated in ndnSIM simulation and a Mininet Go prototype. The central claims are that MARS safely expands usable forwarding opportunities beyond ECMP-limited paths, reduces max p95 flow completion time by up to 81.5% over ECMP-limited baselines, and remains competitive or better than path-expanded end-to-end oracle baselines, with additional robustness under packet loss and transient failures. The paper's safety argument depends on the invariant that consumer-driven ProbeIdx synchronization prevents looped Interests and backward steering; the current pseudocode does not fully establish this invariant.","tokens_in":19416,"tokens_out":7956,"duration_ms":55870,"significance":"If the safety invariant can be established, MARS would be a useful contribution bridging endpoint-only multipath and routing-level path expansion, with a deployable UDP-overlay design. The evaluation is substantially better controlled than typical for this area: the endpoint-only MARS-ENDPOINT variant separates deployment benefit, the Oracle baselines isolate path exposure from forwarder-assisted control, the controller parameters are fixed a priori rather than fitted, the source code is publicly released, and robustness under loss, fairness, and failure recovery are explicitly measured. The claimed reductions in tail FCT and the ability to beat path-expanded end-to-end baselines are significant and would be of interest to the networking community. The main reason the paper is not immediately acceptable is that its load-bearing safety claim is not actually proved by the presented pseudocode, and the evaluation does not directly measure the absence of loops or backward steering during concurrent lossy discovery.","major_comments":[{"comment":"The consumer-driven synchronization does not implement the stated convergence barrier. Algorithm 5 lines 6-7 allocate a new ProbeIdx when a single received Data has TierConv=true, with no accumulation of convergence acknowledgments across all members of the current tier. Algorithm 5 lines 13-15 then make any forwarder with a lower ProbeIdx call PROBENEXTTIER even if its PendingConv set is non-empty. Since Algorithm 4 declares tier convergence only locally at a single forwarder, a lost or delayed Data/NACK from one tier member lets the consumer advance and a lagging forwarder probe tier t+1 before tier t has converged. Algorithm 2 line 4 only removes the local downstream ingress face, and the theta threshold in Algorithm 3 is applied only at initial grouping, so neither mechanism repairs a cross-node synchronization violation. The paper's own Appendix A shows that such violations produce looped Interests and backward steering, yet the evaluation does not measure loop or backward-steering occurrences during concurrent lossy discovery. Please either prove the invariant under the current pseudocode or revise the algorithm to enforce a true multi-node convergence barrier, and then re-run the loss experiments with a direct safety metric.","section":"III-B2 / Appendix D, Algorithm 5"},{"comment":"The headline FCT reductions are reported as point estimates without repeated-run confidence intervals. In Fig. 8, each scale yields a single max p95 FCT value; in Fig. 12 and Table I, the reported ranges are across five consumer groups in one emulation, not independent repetitions. The 73.6%-81.5% reductions and the MARS-versus-Oracle differences in Fig. 12 (e.g., 5.13 s versus 4.53-6.52 s) may therefore be within run-to-run noise. Please add multiple ns-3 seeds or repeated Mininet runs with confidence intervals, or explicitly justify why the emulation is deterministic and why group-level dispersion is the appropriate error model.","section":"V.C / V.D"},{"comment":"The simulation comparison to MPQUIC uses an implementation whose application sends at fixed intervals, which the paper acknowledges handicaps that baseline. The paper nevertheless includes MPQUIC in the simulation FCT comparison and in the abstract's summary of gains over ECMP-limited baselines. Please either replace the fixed-interval MPQUIC sender with a backpressure-driven bulk sender in simulation, or explicitly exclude MPQUIC from simulation-based FCT claims; the current sentence that 'part of MPTCP's advantage reflects the baseline applications' does not address the relevant risk that part of MARS's apparent advantage over MPQUIC reflects the baseline application model.","section":"V.C.2"}],"minor_comments":[{"comment":"The metric 'max p95 FCT' is used throughout but never precisely defined; please state whether the maximum is taken over consumer groups, over flows, or over experimental repetitions.","section":"V.A"},{"comment":"The predicate TIERCONVERGED(D) is used in Algorithm 5 line 6 but is not defined in the pseudocode; please specify whether it inspects the TierConv flag carried in a single Data packet and, if so, state that explicitly.","section":"Appendix D, Algorithm 5"},{"comment":"Table I normalizes path-discovery time by FCT using a separate 36 MB emulation run; please clarify whether that run used the same workload and contention pattern as the main experiments, since the normalized cost could otherwise be misleading.","section":"V.D.2"},{"comment":"The caption of Fig. 10 refers to the 'worst-flow goodput trace' without defining which flow is 'worst'; please specify the selection criterion (e.g., lowest average goodput, latest completion).","section":"V.D.3"},{"comment":"The RTO margin beta=2 and the controller thresholds in Algorithm 1 are fixed values with no sensitivity analysis; a short robustness check for beta and Q_high/Q_low would strengthen the claim that the design is not tuned to the evaluated scenarios.","section":"Appendix B"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is within the journal's scope and the code release is a clear strength. The main correctness concern in Section III-B2 / Algorithm 5 is load-bearing but appears fixable within the paper's scope: implement a genuine convergence barrier and add a direct safety metric during lossy discovery. I would not reject on the current evidence, but the safety claim must be repaired before publication. The FCT confidence-interval issue should also be addressed in the revision, since the paper's quantitative headline depends on point estimates."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: MARS is a real contribution to the ICN/overlay multipath line of work, and its evaluation is well designed, but the paper's central correctness claim about safe path expansion doesn't hold up in the pseudocode as written. The stress-test note is right.\n\nWhat's genuinely new here is the tier-synchronized, consumer-driven path discovery with hop-tier grouping, plus the coupled per-prefix/per-face queue-feedback congestion control. The oracle baselines, where the same MARS-discovered path set is statically installed for MPTCP/MPQUIC, are a solid way to separate the value of path exposure from the value of forwarder-assisted scheduling. The paper is also honest about the MPQUIC baseline's fixed-interval application and about the deployment-dependent nature of the gains.\n\nThe soft spot is load-bearing. Section III-B2 states that the consumer advances the probe index only after all nodes in the current tier have converged, and the paper argues this preserves forward progress. Algorithm 5 doesn't do that. It allocates a new ProbeIdx as soon as a single Data packet arrives with TierConv=true. If another member of the same tier is still probing, its Data is lost or delayed, the consumer advances, and the lagging forwarder receives the higher ProbeIdx and probes its next tier before finishing the current one. Algorithm 2's removal of the downstream ingress face is local and cannot fix this. The result is that loop-free and backward-steering-free operation under loss and asynchrony is not actually proven. The paper's own Appendix A shows the pathologies that appear when this invariant fails. This is a correctness gap, not a stylistic nit.\n\nFor the record, this doesn't invalidate the empirical results as measurements on the tested topologies; those may well be correct. But the headline claim is that MARS 'safely' expands paths, and the safety guarantee is not established by the text.\n\nMinor complaints: FCT numbers in the simulation section are reported without confidence intervals across repeated runs, and the MPQUIC baseline issue is acknowledged but the simulation result still leans on it. The fixed a-priori parameters for the controller are a plus.\n\nWho should read this: anyone working on multipath transport, ICN forwarding, or overlay congestion control. It deserves a serious referee; the mechanism is new, the evaluation is honest and reasonably controlled, and the safety gap is addressable—either by proving the invariant under the actual implementation or by fixing the algorithm to accumulate convergence across all tier members before advancing. I'd engage with it.","headline":"A genuinely new ICN-overlay multipath design with a strong evaluation, but the load-bearing safety invariant of tier-synchronized discovery is not actually enforced by the pseudocode.","tokens_in":19923,"tokens_out":4174,"would_cite":true,"duration_ms":31419,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that a receiver-driven, forwarder-assisted UDP overlay can safely expand usable WAN path diversity and cut tail flow completion time by up to 81.5% over ECMP-limited end-to-end multipath, without changing IP routing.","keywords":["multipath transport","receiver-driven","overlay forwarding","congestion control","path discovery","flow completion time","WAN","queue feedback"],"falsifier":"Re-run the loop-prone forwarding scenario from the paper's Appendix A with 1–5% random loss applied selectively to Data packets carrying TierConv flags, and observe whether any Interest traverses a forwarder twice or moves topologically backward; if a loop or backward hop appears, the safety property under loss fails.","tokens_in":18897,"feed_emoji":"🌐","tokens_out":5571,"duration_ms":48046,"temperature":0.7,"pith_summary":"MARS is a transport that couples receiver-driven Interest/Data retrieval with cooperating overlay forwarders to widen the set of usable paths in wide-area networks without touching IP routing. The paper's central claim is that tier-synchronized path discovery plus queue-feedback congestion control can safely expand forwarding opportunities, avoiding loops and backward steering, and react near bottlenecks. Evaluations show that with cooperating forwarders MARS reduces maximum p95 flow completion time by up to 81.5% relative to ECMP-limited MPTCP/MPQUIC baselines, while remaining competitive in endpoint-only deployment and outperforming path-expanded oracle baselines under loss. If correct, service-managed relays and CDN-like nodes can serve as a practical middle ground between endpoint-only and routing-level multipath.","feed_headline":"MARS cuts WAN flow times by 81.5% without changing IP routing","feed_subtitle":"A receiver-driven overlay discovers safe extra paths and coordinates congestion control near bottlenecks, with no router changes.","key_machinery":"The load-bearing mechanism is tier-synchronized overlay path discovery paired with coupled congestion control. Forwarders group eligible upstream next hops into hop-tiers, probe shortest-hop tiers first, and the consumer advances a probe index only after Data metadata reports that the current tier has converged (TierConv flag), preventing upstream nodes from probing later tiers before downstream nodes have settled. In parallel, per-face and per-prefix rate control uses the reported upstream Interest and Data queue sizes and their slopes to choose increase, hold, or decrease responses, bounding the rate by a smoothed bandwidth estimate. These two mechanisms together avoid loops, backward steering, and path inflation while letting downstream nodes react closer to where congestion forms.","core_discovery":"The paper's central discovery is that consumer-driven, tier-synchronized overlay path discovery lets a forwarder-assisted transport expand its usable path set without creating loops, backward steering, or excessive path inflation. In the evaluated WAN topology, MARS discovers five usable paths per pair where ECMP exposes one, and ten paths through the core in the larger simulation. Combined with a coupled consumer/forwarder congestion controller that reads upstream Interest- and Data-queue sizes as early congestion signals, this reduces maximum p95 flow completion time by about 73.6% to 81.5% relative to ECMP-limited end-to-end multipath, and gives lower worst-case p95 FCT than oracle baselines that statically see the same path set, especially under packet loss.","pith_inferences":["The tier-synchronization idea is not inherently tied to ICN naming; a testable extension is porting the discovery and queue-feedback control to a QUIC-based relay overlay, where similar forwarder-assisted gains might appear.","The safety argument is algorithmic and was exercised only in moderate loss and failure tests; a formal model or adversarial-loss simulation that drops TierConv flags would clarify whether loops can reappear under extreme asynchrony.","The oracle-baseline comparison implies that MARS's value comes from coordinated control rather than path exposure alone, so other multipath systems with static route diversity should expect diminishing robustness in lossy WANs.","Because the evaluation uses a fixed representative topology, the quantitative gains are not universal; repeating the experiments on topologies with more asymmetric routing policies would bound how deployment-dependent the results are."],"forward_implications":["Operators can deploy multipath across cooperating relays, CDN nodes, and edge servers without changing IP routers or routing protocols.","Endpoint-only MARS remains competitive with MPTCP and MPQUIC, so there is no deployment penalty for starting with a minimal footprint.","The advantage over oracle baselines under loss shows that static path expansion alone is fragile; coordinated forwarder feedback is what preserves robustness.","Path discovery overhead is low (packets around 106–115 bytes, startup below 0.7 seconds, under 3% of flow completion time), making it practical in production overlays.","In transient link-failure tests MARS degrades gracefully (max p95 FCT increases by roughly 3.5%) and re-converges after repair, which suits failure-prone WANs."],"supporting_citations":[{"why":"Serves as the state-of-the-art forwarder-assisted congestion-control baseline whose uncoordinated next-hop expansion MARS's discovery mechanism is designed to fix.","marker":"[18]"},{"why":"Supplies the MPQUIC baseline, an end-to-end UDP multipath transport MARS is compared against.","marker":"[8]"},{"why":"Supplies the MPTCP baseline, an end-to-end TCP multipath transport MARS is compared against.","marker":"[24]"},{"why":"Defines ECMP routing, which limits the path visibility available to the end-to-end baselines.","marker":"[10]"},{"why":"Introduces the upstream queue-size feedback idea that MARS's coupled congestion control builds on.","marker":"[19]"},{"why":"Supplies the MPQUIC simulation baseline used for comparison in the large-scale evaluation.","marker":"[37]"},{"why":"Provides the simulator in which MARS is implemented and evaluated at scale.","marker":"[30]"},{"why":"Supplies the routing that installs the multiple next-hop sets that MARS's tier grouping filters into safe forwarding choices.","marker":"[22]"}],"fun_headline_variants":["MARS overlays cut WAN flow times by 81.5%","Receiver-driven multipath: 81.5% faster without router changes","MARS discovers extra paths, slashes p95 flow times","Overlay multipath cuts WAN delays up to 81.5%","MARS: end-to-end multipath, no IP reconfiguration"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The design assumes that consumer-driven probe-index synchronization keeps every forwarder from advancing to a later tier before downstream convergence is known, even when Data carrying TierConv flags is lost or a forwarder's next-hop table changes mid-discovery.","fun_headline_variants_meta":{"raw":{"variants":["MARS overlays cut WAN flow times by 81.5%","Receiver-driven multipath: 81.5% faster without router changes","MARS discovers extra paths, slashes p95 flow times","Overlay multipath cuts WAN delays up to 81.5%","MARS: end-to-end multipath, no IP reconfiguration"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000596,"raw_usage":{"total_tokens":2824,"prompt_tokens":1016,"completion_tokens":1808,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":632,"completion_tokens_details":{"reasoning_tokens":1713}},"tokens_in":632,"tokens_out":1808,"duration_ms":10135,"temperature":1.0,"reasoning_tokens":1713,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T14:49:39.023035+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Re-run the loop-prone forwarding scenario from the paper's Appendix A with 1–5% random loss applied selectively to Data packets carrying TierConv flags, and observe whether any Interest traverses a forwarder twice or moves topologically backward; if a loop or backward hop appears, the safety property under loss fails.","supporting_citations":[{"cited_title":"Design, implementation and evaluation of congestion control for multipath TCP,","cited_arxiv_id":null,"evidence_quote":"Supplies the MPTCP baseline, an end-to-end TCP multipath transport MARS is compared against."},{"cited_title":"Analysis of an Equal-Cost Multi-Path Algorithm,","cited_arxiv_id":null,"evidence_quote":"Defines ECMP routing, which limits the path visibility available to the end-to-end baselines."},{"cited_title":"A multipath extension to the QUIC module for ns-3,","cited_arxiv_id":null,"evidence_quote":"Supplies the MPQUIC simulation baseline used for comparison in the large-scale evaluation."},{"cited_title":"ndnSIM 2: An updated NDN simulator for NS-3,","cited_arxiv_id":null,"evidence_quote":"Provides the simulator in which MARS is implemented and evaluated at scale."},{"cited_title":"Poster: Distance vector routing for named data networking,","cited_arxiv_id":null,"evidence_quote":"Supplies the routing that installs the multiple next-hop sets that MARS's tier grouping filters into safe forwarding choices."}],"review_version":1}