Pith. sign in

REVIEW 3 major objections 5 minor 44 references

MARS: Multipath Adaptive Reliable Service

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 2608.06101 v1 pith:E27R2JC3 submitted 2026-08-06 cs.NI

Yitong Li , Xinjiao Li , Dirk Kutscher This is my paper · ORCID
classification cs.NI
keywords multipathtransportreceiver-drivenoverlayforwardingcongestioncontrolpathdiscoveryflowcompletiontimeWANqueuefeedback
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

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.

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 (3)
  1. [III-B2 / Appendix D, Algorithm 5] 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.
  2. [V.C / V.D] 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.
  3. [V.C.2] 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.
minor comments (5)
  1. [V.A] 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.
  2. [Appendix D, Algorithm 5] 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.
  3. [V.D.2] 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.
  4. [V.D.3] 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).
  5. [Appendix B] 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.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: MARS's FCT gains are measured against external baselines; oracle path reuse is an explicit ablation, and the only author self-citation is background.

full rationale

The paper's central claims are empirical. The 81.5% max p95 FCT reduction is a measured result against PCON, MPTCP, and MPQUIC baselines in ndnSIM/ns-3 and Mininet, not a quantity derived from fitted parameters; Algorithm 1 fixes controller parameters a priori ('we do not tune them per topology or workload'). The Oracle baselines reuse MARS-discovered paths by design, but the paper explicitly states they 'do not receive MARS queue feedback, path-discovery state, or forwarder-side scheduling; they receive only static path exposure,' making this an ablation that isolates path-set gain rather than a prediction forced by the mechanism. No fitted input is renamed as a prediction, no uniqueness theorem is imported from the authors' prior work, and no ansatz is smuggled in via citation. The one self-citation (Kutscher's ICN survey [15]) is background only and not load-bearing. The tier-synchronization loop-freedom invariant is asserted algorithmically (Section III-B and Appendix D); even if the skeptic's concern about Algorithm 5 advancing ProbeIdx after a single TierConv Data is a genuine correctness gap, it is a robustness and safety issue, not a circular reduction of the evaluated performance to the paper's own definitions.

Assumptions & free parameters 4 free parameters · 5 assumptions · 0 invented entities

The central claims rest on hand-set protocol parameters, on cooperative-overlay trust assumptions, on the availability of multi-hop FIB state, and on the unproven safety of tier-synchronized loop avoidance under adverse conditions. No free parameters are fitted to the reported results.

free parameters (4)
  • per-prefix Interest queue capacity Q_max = 40
    Chosen by hand as a default; affects shaping behavior and congestion feedback sensitivity (Section III-A1).
  • Congestion controller thresholds and gains (Q_high, Q_low, S_thres, MD, GD, CI, AI, alpha_strong, alpha_small… = 0.8, 0.5, 0.1, 0.7, 0.95, 1.02, 1.1, 0.25, 0.1, 0.5, 1.2
    Hand-set constants in Algorithm 1; the paper states they are not tuned per topology or workload, but they are not derived from first principles.
  • RTO margin beta = 2
    Conservative multiplier on the Jacobson/Karels RTO to reduce spurious retransmissions under multipath RTT variation (Appendix B).
  • Hop-count threshold theta = unspecified
    Section III-B1 defines a threshold theta on hop count relative to the shortest path, but the value used in experiments is not reported; it controls the bound on path inflation.
assumptions (5)
  • domain assumption Forwarders are trusted, non-Byzantine, and report queue metadata faithfully.
    Section III 'Trust boundary' explicitly assumes cooperative, authorized forwarders; false reporting is outside the threat model.
  • domain assumption The underlying routing (e.g., ndn-dv, NLSR) provides multiple next hops and hop counts for each prefix.
    Path discovery (Algorithm 3) starts from ALLNEXTHOPSFROMFIB and uses hop counts h[p,f] to group tiers; without such routing state, discovery cannot expand paths.
  • domain assumption Interest/Data exchange with per-hop queue feedback is available at all participating nodes.
    The congestion control relies on Q_int and Q_data metadata carried in Data packets (Section III-A2).
  • domain assumption The workload consists of large transfers where path discovery overhead (0.3-0.7 s) is a small fraction of FCT.
    The evaluation uses 18-36 MB objects; the abstract scopes the claims to 'large data volumes.' For short flows, PD startup delay could dominate.
  • ad hoc to paper Hop-tier grouping and consumer-driven ProbeIdx synchronization suffice to prevent loops and backward steering under concurrent, lossy conditions.
    This is the load-bearing safety property (Appendix D); it is argued algorithmically and tested in limited scenarios, but not proven for arbitrary asynchronous failures.

how reviews work

0 comments
Cite this review

Pith. "Pith review of MARS: Multipath Adaptive Reliable Service." pith.science (2026). https://pith.science/paper/E27R2JC3

@misc{pith2026260806101,
  author       = {Pith},
  title        = {Pith review of: MARS: Multipath Adaptive Reliable Service},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/E27R2JC3}},
  note         = {Machine review of arXiv:2608.06101}
}
read the original abstract

Multipath transport is increasingly important for Internet/WAN services that move large data volumes across heterogeneous paths, including geo-distributed analytics, content distribution, and cloud-service pipelines. Existing solutions, however, face a practical trade-off: end-to-end transports such as MPTCP and MPQUIC are deployable but limited by endpoint-visible paths and delayed congestion feedback, while routing-or forwarder-assisted approaches often require infrastructure support or lack safe coordination across forwarding choices. This paper presents MARS, a receiver-driven, forwarder-assisted multipath transport for Internet/WAN environments. MARS combines tier-synchronized overlay path discovery with coupled consumer/forwarder congestion control, enabling it to safely expand usable forwarding opportunities and react near bottlenecks. It runs as an incrementally deployable UDP overlay at clients, servers, relays, or CDN-like nodes. We implement MARS in simulation and as a prototype, and evaluate it through large-scale simulation and Mininet emulation under different deployment scales, loss rates, and failure scenarios. The results show that MARS provides deployment-dependent benefits: with endpoint-only deployment, it remains competitive with end-to-end multipath baselines; with cooperating overlay forwarders, it exposes richer usable path diversity and reduces max p95 flow completion time by up to 81.5\% over ECMP-limited baselines. Even against path-expanded end-to-end baselines given the same path set, MARS achieves lower worst-case p95 FCT and stronger robustness under packet loss, while also recovering quickly from transient link failures. These results demonstrate that ICN-style receiver-driven forwarding can serve as a deployable overlay transport substrate for WAN multipath, providing benefits beyond purely end-to-end designs without requiring changes to IP routing.

Figures

Figures reproduced from arXiv: 2608.06101 by the authors.

Figure 1
Figure 1. PCON [18] performance degradation under loop-free and loop-prone [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. MARS vs. endpoint-only multipath transports. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. MARS forwarder design MARS forwarders maintain per-prefix queues, schedule Inter￾ests over upstream faces, and return Data along reverse paths; producers remain transparent to the multipath logic. As [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (8 more)
Figure 5
Figure 5. Figure 5: Challenge without synchro [PITH_FULL_IMAGE:figures/full_fig_p003_5.png]
Figure 6
Figure 6. Figure 6: Path discovery pipeline To avoid unsafe tier advancement without global synchro￾nization, path discovery is coordinated in a consumer-driven manner (see Section III-B2). To ensure path discovery con￾verges, efficient convergence mechanisms are implemented (see Section …
Figure 7
Figure 7. Figure 7: WAN evaluation topology a mesh-like core, and servers attach to the core through multiple access links. This structure provides multiple for￾warding opportunities while preserving the asymmetric and unbalanced connectivity typical of wide-area deployments. We evaluate …
Figure 8
Figure 8. Figure 8: Sim: max p95 FCT vs. scale [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 11
Figure 11. Figure 11: Minimal deployment: p95 FCT under loss [PITH_FULL_IMAGE:figures/full_fig_p008_11.png]
Figure 15
Figure 15. Figure 15: Incremental deployment: p95 FCT under loss [PITH_FULL_IMAGE:figures/full_fig_p008_15.png]
Figure 17
Figure 17. Figure 17: Jain fairness of per-flow average application goodput. Markers [PITH_FULL_IMAGE:figures/full_fig_p009_17.png]
Figure 18
Figure 18. Figure 18: Common anomalies in ICN multipath forwarding arising from uncoordinated local decisions. [PITH_FULL_IMAGE:figures/full_fig_p014_18.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

44 extracted references · 36 canonical work pages

  1. [1]

    Facts and Figures 2024: Internet Traffic,

    International Telecommunication Union, “Facts and Figures 2024: Internet Traffic,” https://www.itu.int/itu-d/reports/statistics/2024/11/10/ ff24-internet-traffic/, Nov. 2024, accessed: 2026-05-12

    work page 2024

  2. [2]

    Mobile Network Traffic Q4 2025,

    Ericsson, “Mobile Network Traffic Q4 2025,” https://www. ericsson.com/en/reports-and-papers/mobility-report/dataforecasts/ mobile-traffic-update, 2026, ericsson Mobility Report data forecast. Accessed: 2026-05-12

    work page 2025

  3. [3]

    Improving Training Time and GPU Utilization in Geo-distributed Language Model Training,

    Palak, T. R. Reddy, B. Kataria, R. Gandhi, K. Tandon, D. Bhattacherjee, and V . N. Padmanabhan, “Improving Training Time and GPU Utilization in Geo-distributed Language Model Training,” 2024. [Online]. Available: https://arxiv.org/abs/2411.14458

    arXiv 2024

  4. [4]

    Accelerating Geo-distributed Machine Learning with Network-Aware Adaptive Tree and Auxiliary Route

    Z. Li, W. Feng, W. Cai, H. Yu, L. Luo, G. Sun, H. Du, and D. Niyato, “Accelerating Geo-distributed Machine Learning with Network-Aware Adaptive Tree and Auxiliary Route,” 2024. [Online]. Available: https://arxiv.org/abs/2404.11352

    work page Pith review arXiv 2024

  5. [5]

    Deep neural networks for youtube recommendations,

    P. Covington, J. Adams, and E. Sargin, “Deep neural networks for youtube recommendations,” inProceedings of the 10th ACM Conference on Recommender Systems, ser. RecSys ’16. New York, NY , USA: Association for Computing Machinery, 2016, p. 191–198. [Online]. Available: https://doi.org/10.1145/2959100.2959190

    arXiv 2016

  6. [6]

    TCP Extensions for Multipath Operation with Multiple Addresses,

    A. Ford, C. Raiciu, M. J. Handley, O. Bonaventure, and C. Paasch, “TCP Extensions for Multipath Operation with Multiple Addresses,” RFC 8684, Mar. 2020. [Online]. Available: https://www.rfc-editor.org/ info/rfc8684

    work page 2020

  7. [7]

    Concurrent multipath transfer using sctp multihoming over heterogeneous network paths,

    T. Kim, J. Lee, and Y . I. Eom, “Concurrent multipath transfer using sctp multihoming over heterogeneous network paths,” inICCAS 2010, 2010, pp. 1598–1602

    work page 2010

  8. [8]

    Multipath quic: Design and evaluation,

    Q. De Coninck and O. Bonaventure, “Multipath quic: Design and evaluation,” inProceedings of the 13th International Conference on Emerging Networking EXperiments and Technologies, ser. CoNEXT ’17. New York, NY , USA: Association for Computing Machinery, 2017, p. 160–166. [Online]. Available: https://doi.org/10.1145/3143361.3143370

    arXiv 2017

Show all 44 references
  1. [9]

    Managing multiple paths for a QUIC connection,

    Y . Liu, Y . Ma, Q. D. Coninck, O. Bonaventure, C. Huitema, and M. K ¨uhlewind, “Managing multiple paths for a QUIC connection,” Internet Engineering Task Force, Internet-Draft draft-ietf-quic-multipath- 21, Mar. 2026, work in Progress. [Online]. Available: https: //datatracke...

    2026

  2. [10]

    Analysis of an Equal-Cost Multi-Path Algorithm,

    C. Hopps, “Analysis of an Equal-Cost Multi-Path Algorithm,” RFC 2992, Nov. 2000. [Online]. Available: https://www.rfc-editor.org/info/ rfc2992

    2000

  3. [11]

    Yamr: yet another multipath routing protocol,

    I. Ganichev, B. Dai, P. B. Godfrey, and S. Shenker, “Yamr: yet another multipath routing protocol,”SIGCOMM Comput. Commun. Rev., vol. 40, no. 5, p. 13–19, Oct. 2010. [Online]. Available: https://doi.org/10.1145/1880153.1880156

    2010

  4. [12]

    Miro: multi-path interdomain routing,

    W. Xu and J. Rexford, “Miro: multi-path interdomain routing,” in Proceedings of the 2006 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, ser. SIGCOMM ’06. New York, NY , USA: Association for Computing Machinery, 2006, p. 171–...

    2006

  5. [13]

    Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken),

    S. Dawkins, “Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken),” RFC 9049, Jun. 2021. [Online]. Available: https://www.rfc-editor.org/info/rfc9049

    2021

  6. [14]

    Adding path awareness to the internet architecture,

    B. Trammell, J.-P. Smith, and A. Perrig, “Adding path awareness to the internet architecture,”IEEE Internet Computing, vol. 22, no. 2, pp. 96–102, 2018

    2018

  7. [15]

    A survey of information-centric networking,

    B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, and B. Ohlman, “A survey of information-centric networking,”IEEE Communications Magazine, vol. 50, no. 7, pp. 26–36, 2012

    2012

  8. [16]

    Resilient overlay networks,

    D. Andersen, H. Balakrishnan, F. Kaashoek, and R. Morris, “Resilient overlay networks,”SIGOPS Oper. Syst. Rev., vol. 35, no. 5, p. 131–145, Oct. 2001. [Online]. Available: https://doi.org/10.1145/502059.502048

    2001

  9. [17]

    Overlay tcp for multi-path routing and congestion control,

    H. Han, S. Shakkottai, C. Hollot, R. Srikant, and D. Towsley, “Overlay tcp for multi-path routing and congestion control,” inIMA Workshop on Measurements and Modeling of the Internet, 2004

    2004

  10. [19]

    Effective ndn congestion control based on queue size feedback,

    S. Song and L. Zhang, “Effective ndn congestion control based on queue size feedback,” inProceedings of the 9th ACM Conference on Information-Centric Networking, ser. ICN ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 11–21. [Online]. Available: https:/...

    2022

  11. [20]

    Mircc: Multipath- aware icn rate-based congestion control,

    M. Mahdian, S. Arianfar, J. Gibson, and D. Oran, “Mircc: Multipath- aware icn rate-based congestion control,” inProceedings of the 3rd ACM Conference on Information-Centric Networking, ser. ACM-ICN ’16. New York, NY , USA: Association for Computing Machinery, 2016, p. 1–10. [O...

    2016

  12. [21]

    Quic: A udp-based multiplexed and secure transport,

    J. Iyengar and M. Thomson, “Quic: A udp-based multiplexed and secure transport,” RFC 9000, May 2021. [Online]. Available: https://www.rfc-editor.org/info/rfc9000

    2021

  13. [22]

    Poster: Distance vector routing for named data networking,

    V . Patil, S. Theeranantachai, B. Zhang, and L. Zhang, “Poster: Distance vector routing for named data networking,” inProceedings of the 20th International Conference on emerging Networking EXperiments and Technologies, 2024, pp. 23–24

    2024

  14. [23]

    Nlsr: Named-data link state routing protocol,

    A. M. Hoque, S. O. Amin, A. Alyyan, B. Zhang, L. Zhang, and L. Wang, “Nlsr: Named-data link state routing protocol,” inProceedings of the 3rd ACM SIGCOMM workshop on Information-centric networking, 2013, pp. 15–20

    2013

  15. [24]

    Design, implementation and evaluation of congestion control for multipath TCP,

    D. Wischik, C. Raiciu, A. Greenhalgh, and M. Handley, “Design, implementation and evaluation of congestion control for multipath TCP,” in8th USENIX Symposium on Networked Systems Design and Implementation (NSDI 11). Boston, MA: USENIX Association, Mar

  16. [25]

    Improving datacenter performance and robustness with multipath tcp,

    C. Raiciu, S. Barre, C. Pluntke, A. Greenhalgh, D. Wischik, and M. Handley, “Improving datacenter performance and robustness with multipath tcp,”ACM SIGCOMM Computer Communication Review, vol. 41, no. 4, pp. 266–277, 2011

    2011

  17. [26]

    End-to-end routing behavior in the internet,

    V . Paxson, “End-to-end routing behavior in the internet,” inConference Proceedings on Applications, Technologies, Architectures, and Protocols for Computer Communications, ser. SIGCOMM ’96. New York, NY , USA: Association for Computing Machinery, 1996, p. 25–38. [Online]. Ava...

    1996

  18. [27]

    How asymmetric is the internet?: A study to support the use of traceroute,

    W. de Vries, J. Santanna, A. Sperotto, and A. Pras, “How asymmetric is the internet?: A study to support the use of traceroute,” 06 2015

    2015

  19. [28]

    Muca: New routing for named data networking,

    C. Ghasemi, H. Yousefi, K. G. Shin, and B. Zhang, “Muca: New routing for named data networking,” in2018 IFIP Networking Conference (IFIP Networking) and Workshops. IEEE, 2018, pp. 289–297

    2018

  20. [29]

    Congestion avoidance and control,

    V . Jacobson, “Congestion avoidance and control,” inSymposium Proceedings on Communications Architectures and Protocols, ser. SIGCOMM ’88. New York, NY , USA: Association for Computing Machinery, 1988, p. 314–329. [Online]. Available: https://doi.org/10. 1145/52324.52356

    1988

  21. [30]

    ndnSIM 2: An updated NDN simulator for NS-3,

    S. Mastorakis, A. Afanasyev, I. Moiseenko, and L. Zhang, “ndnSIM 2: An updated NDN simulator for NS-3,” NDN, Technical Report NDN- 0028, Revision 2, Nov. 2016

    2016

  22. [31]

    On the evolution of ndnsim: an open-source simulator for ndn experimentation,

    S. Mastorakis, A. Afanasyev, and L. Zhang, “On the evolution of ndnsim: an open-source simulator for ndn experimentation,”SIGCOMM Comput. Commun. Rev., vol. 47, no. 3, p. 19–33, Sep. 2017. [Online]. Available: https://doi.org/10.1145/3138808.3138812

    2017

  23. [32]

    The ns-3 network simulator,

    G. F. Riley and T. R. Henderson, “The ns-3 network simulator,” in Modeling and Tools for Network Simulation, J. G. K. Wehrle, M. G ¨unes, Ed. Springer, 2010, pp. 15–34

    2010

  24. [33]

    NDNd: Golang implementation of the named data networking protocol stack,

    Named Data Networking, “NDNd: Golang implementation of the named data networking protocol stack,” https://github.com/named-data/ndnd, 2025, version 1.5.2

    2025

  25. [34]

    Dinc: Toward distributed in-network computing,

    C. Zheng, H. Tang, M. Zang, X. Hong, A. Feng, L. Tassiulas, and N. Zil- berman, “Dinc: Toward distributed in-network computing,”Proceedings of the ACM on Networking, vol. 1, no. CoNEXT3, pp. 1–25, 2023

    2023

  26. [35]

    B4: experience with a globally-deployed software defined wan,

    S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh, S. Venkata, J. Wanderer, J. Zhou, M. Zhu, J. Zolla, U. H ¨olzle, S. Stuart, and A. Vahdat, “B4: experience with a globally-deployed software defined wan,” inProceedings of the ACM SIGCOMM 2013 Conference on SIGCOMM...

    2013

  27. [36]

    Multipath-TCP in ns-3,

    M. Kheirkhah, I. Wakeman, and G. Parisis, “Multipath-TCP in ns-3,” CoRR, 2015. [Online]. Available: http://arxiv.org/abs/1510.07721

    2015 arXiv

  28. [37]

    A multipath extension to the QUIC module for ns-3,

    S. Shu, W. Yang, J. Pan, and L. Cai, “A multipath extension to the QUIC module for ns-3,” inProceedings of the 2023 Workshop on ns-3. New York, NY , USA: Association for Computing Machinery, 2023, pp. 86–93. [Online]. Available: https://doi.org/10.1145/3592149.3592803

    2023

  29. [38]

    A network in a laptop: Rapid prototyping for software-defined networks,

    B. Lantz, B. Heller, and N. McKeown, “A network in a laptop: Rapid prototyping for software-defined networks,” inProceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks, ser. HotNets-IX. New York, NY , USA: ACM, 2010

    2010

  30. [39]

    Stream Control Transmission Protocol,

    R. R. Stewart, M. T ¨uxen, and K. Nielsen, “Stream Control Transmission Protocol,” RFC 9260, Jun. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9260

    2022

  31. [40]

    Proxying UDP in HTTP,

    D. Schinazi, “Proxying UDP in HTTP,” RFC 9298, Aug. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9298

    2022

  32. [41]

    Analysis of the increase and decrease algorithms for congestion avoidance in computer networks,

    D.-M. Chiu and R. Jain, “Analysis of the increase and decrease algorithms for congestion avoidance in computer networks,”Comput. Netw. ISDN Syst., vol. 17, no. 1, p. 1–14, Jun. 1989. [Online]. Available: https://doi.org/10.1016/0169-7552(89)90019-6 APPENDIX A. Unsafe Path Expa...

    1989 doi

  33. [43]

    PCON is implemented using its original ndnSIM- based codebase 2, where ndnSIM runs on top of ns-3

    Simulation Implementation:The simulation evaluation includes four solutions: PCON, MPTCP, MPQUIC, and MARS. PCON is implemented using its original ndnSIM- based codebase 2, where ndnSIM runs on top of ns-3. We use PCON as the primary ICN forwarder-assisted congestion- control ...

  34. [44]

    It uses MPQUIC as the end-to-end transport substrate for client-server data delivery

    Emulation Implementation: a) MPQUIC:Our MPQUIC baseline is built by adapting the open-source MPQUIC implementation 5 to our Mininet emulation workload. It uses MPQUIC as the end-to-end transport substrate for client-server data delivery. Each sender establishes one logical MPQ...

  35. [45]

    Converged

    Fairness Metric:We quantify fairness separately within each consumer group because its five flows compete through the same consumer-side scheduling context. Each flow is configured to transfer an 18 MB object. For flowi, letx i denote its average application goodput, measured ...

  36. [2011]

    Available: https://www.usenix.org/conference/nsdi11/ design-implementation-and-evaluation-congestion-control-multipath-tcp

    [Online]. Available: https://www.usenix.org/conference/nsdi11/ design-implementation-and-evaluation-congestion-control-multipath-tcp

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.