pith. sign in

arxiv: 2504.10054 · v2 · submitted 2025-04-14 · 💻 cs.NI

Implementation and Performance Evaluation of TCP over QUIC Tunnels

Xuanhong Guo , Zekun Bao , Ying Chen This is my paper

Pith reviewed 2026-05-22 20:56 UTC · model grok-4.3

classification 💻 cs.NI
keywords TCPQUICtunnelingperformance evaluationpacket lossthroughputtransport protocolsnetwork conditions
0
0 comments X

The pith

TCP traffic sent inside QUIC tunnels keeps higher throughput than native TCP once packet loss appears.

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

The work constructs a lightweight tunnel so that ordinary TCP applications can send their streams over QUIC connections without changing their code. Experiments place the tunnel under controlled loss, delay, and reordering and compare its throughput against plain TCP on the same paths. When loss reaches 20 percent the tunneled flows move substantially more data, because QUIC's recovery hides the losses from the TCP layer above it. Under perfect conditions the extra encryption and user-space work adds only modest overhead. A reader who still runs legacy TCP programs on wireless or congested links would therefore see a concrete way to improve speed without rewriting the applications.

Core claim

A lightweight stream-based tunnel built with the Quinn library lets TCP traffic traverse QUIC connections transparently. Under lossy or unstable network conditions this arrangement yields significantly higher throughput than native TCP, with marked gains at 20 percent packet loss, while adding only modest overhead when the network is ideal.

What carries the argument

The lightweight stream-based tunnel constructed using the Quinn library, which carries TCP segments inside QUIC streams to supply transparent transport and loss recovery.

Load-bearing premise

The tunnel passes TCP segments transparently and does not introduce its own significant extra losses or delays beyond those already present on the QUIC connection.

What would settle it

A throughput test at 20 percent packet loss in which native TCP matches or exceeds the rate achieved by the tunneled version.

Figures

Figures reproduced from arXiv: 2504.10054 by Xuanhong Guo, Ying Chen, Zekun Bao.

Figure 1
Figure 1. Figure 1: QUIC-Tun architecture: traffic flow from a local TCP client through the QUIC tunnel to a remote TCP server [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: This figure shows the impact of the two connections on throughput at different packet loss rates [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: This figure shows the impact of the two connections on throughput at different lags [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: This figure shows the impact of the two connections on throughput at different out of order rates attributed to the inherent features of QUIC, including stream multiplexing and efficient loss recovery mechanisms. However, our evaluation also reveals the limitations of TCP over QUIC in high-quality network environments. In such conditions, the dual-protocol stack introduces additional computational overhead… view at source ↗
read the original abstract

QUIC, a UDP-based transport protocol, addresses several limitations of TCP by offering built-in encryption, stream multiplexing, and improved loss recovery. To extend these benefits to legacy TCP-based applications, this paper explores the implementation and evaluation of a TCP over QUIC tunneling approach. A lightweight, stream-based tunnel is constructed using the Rust-based Quinn library, enabling TCP traffic to traverse QUIC connections transparently. Performance is evaluated under varying network conditions, including packet loss, high latency, and out-of-order delivery. Results indicate that TCP over QUIC maintains significantly higher throughput than native TCP in lossy or unstable environments, with up to a high improvement under 20\% packet loss. However, under ideal network conditions, tunneling introduces modest overhead due to encryption and user-space processing. These findings provide insights into the trade-offs of TCP over QUIC tunneling and its suitability for deployment in dynamic or impaired networks.

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 manuscript describes the implementation of a lightweight, stream-based TCP-over-QUIC tunnel using the Rust Quinn library to enable transparent forwarding of legacy TCP traffic over QUIC connections. Performance is evaluated against native TCP under emulated conditions of packet loss, high latency, and out-of-order delivery; the central empirical claim is that the tunneled variant sustains significantly higher throughput than native TCP in lossy or unstable environments, with substantial gains reported at 20% packet loss, while incurring modest overhead from encryption and user-space processing under ideal conditions.

Significance. If the throughput measurements prove robust and reproducible, the work supplies practical evidence that QUIC tunneling can improve resilience for unmodified TCP applications in impaired networks. The Quinn-based implementation offers a concrete reference point for similar lightweight proxies, and the reported trade-offs between loss recovery gains and tunneling overhead are relevant to network operators considering QUIC deployment for legacy traffic.

major comments (2)
  1. [Evaluation] Evaluation section: the manuscript supplies no description of the experimental setup, including the network emulation tool, link parameters, trial counts, statistical methods, or error bars. Without these details the claim of 'significantly higher throughput' and 'high improvement under 20% packet loss' cannot be verified or reproduced.
  2. [Results] Results and discussion: the performance comparison does not isolate QUIC loss-recovery effects from artifacts introduced by the user-space tunnel and stream mapping. Additional per-stream state or buffering in the Quinn proxy could alter loss detection timing or congestion signals relative to a direct kernel TCP stack, so the observed gains at 20% loss may not be attributable to QUIC alone.
minor comments (2)
  1. [Abstract] Abstract: the phrase 'up to a high improvement' is imprecise; replace with a concrete percentage or throughput delta supported by the data.
  2. [Implementation] Implementation: clarify whether the native-TCP baseline traversed the same user-space proxy path or ran directly on the kernel stack, to ensure the comparison isolates the QUIC layer.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the detailed and constructive review. We address each major comment below and outline the revisions planned for the manuscript.

read point-by-point responses

  1. Referee: [Evaluation] Evaluation section: the manuscript supplies no description of the experimental setup, including the network emulation tool, link parameters, trial counts, statistical methods, or error bars. Without these details the claim of 'significantly higher throughput' and 'high improvement under 20% packet loss' cannot be verified or reproduced.

    Authors: We agree that the current manuscript lacks sufficient detail on the experimental methodology. In the revised version we will add a dedicated subsection describing the network emulation tool, all link parameters (bandwidth, latency, and loss rates), the number of independent trials per condition, the statistical methods used to compute means and variability, and error bars on all throughput plots. These additions will directly support verification of the reported gains at 20% packet loss. revision: yes

  2. Referee: [Results] Results and discussion: the performance comparison does not isolate QUIC loss-recovery effects from artifacts introduced by the user-space tunnel and stream mapping. Additional per-stream state or buffering in the Quinn proxy could alter loss detection timing or congestion signals relative to a direct kernel TCP stack, so the observed gains at 20% loss may not be attributable to QUIC alone.

    Authors: This concern is valid. The user-space Quinn proxy necessarily introduces buffering and stream-mapping logic that differs from a kernel TCP stack. In the revision we will expand the discussion to describe the proxy's buffering and state management, explicitly note that the measured gains reflect the combined effects of QUIC loss recovery and the tunneling implementation, and qualify the attribution accordingly. We will also clarify that the comparison remains relevant for practical deployment of unmodified TCP applications over QUIC tunnels. revision: partial

Circularity Check

0 steps flagged

Empirical implementation study with no derivations or self-referential claims

full rationale

The paper describes construction of a Quinn-based TCP-over-QUIC stream tunnel followed by direct throughput and latency measurements under controlled loss, latency, and reordering conditions. No equations, fitted parameters, first-principles derivations, or predictions appear in the provided text. All reported gains are presented as outcomes of the experimental runs rather than reductions of prior results or self-citations. The work is therefore self-contained against external replication and receives the default non-circularity finding.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The abstract describes an empirical implementation study and mentions no free parameters, mathematical axioms, or newly postulated entities.

pith-pipeline@v0.9.0 · 5682 in / 1055 out tokens · 67164 ms · 2026-05-22T20:56:06.120093+00:00 · methodology

discussion (0)

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

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

  • IndisputableMonolith/Foundation/RealityFromDistinction.lean reality_from_one_distinction unclear
    ?
    unclear

    Relation between the paper passage and the cited Recognition theorem.

    A lightweight, stream-based tunnel is constructed using the Rust-based Quinn library, enabling TCP traffic to traverse QUIC connections transparently. ... Results indicate that TCP over QUIC maintains significantly higher throughput than native TCP in lossy or unstable environments, with up to a high improvement under 20% packet loss.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

22 extracted references · 22 canonical work pages

  1. [1]

    Journal of King Saud University - Computer and Information Sciences35(10), 101797 (2023)

    Abdelhafez, M., Ramadass, S., Abdelwahab, M.: Tls guard for tls 1.3 zero round-trip time (0-rtt) in a distributed environment. Journal of King Saud University - Computer and Information Sciences35(10), 101797 (2023). https://doi.org/https://doi.org/10.1016/j.jksuci.2023.101797,https:// www.sciencedirect.com/science/article/pii/S1319157823003518

    work page doi:10.1016/j.jksuci.2023.101797 2023

  2. [2]

    In: NOMS 2020 - 2020 IEEE/IFIP Network Operations and Management Symposium

    Bauer, S., Holzinger, K., Jaeger, B., Emmerich, P., Carle, G.: On- line monitoring of tcp throughput limitations. In: NOMS 2020 - 2020 IEEE/IFIP Network Operations and Management Symposium. pp. 1–9 (2020). https://doi.org/10.1109/NOMS47738.2020.9110324

    work page doi:10.1109/noms47738.2020.9110324 2020

  3. [3]

    briansmith: ring: An experiment.https://github.com/briansmith/ring

    work page

  4. [4]

    Internet-Draft draft-davie-stt-06, Internet Engineering Task Force (Apr 2014),https://datatracker.ietf.org/doc/draft-davie-stt/06/, work in Progress

    Davie, B., Gross, J.: A Stateless Transport Tunneling Protocol for Network Virtu- alization (STT). Internet-Draft draft-davie-stt-06, Internet Engineering Task Force (Apr 2014),https://datatracker.ietf.org/doc/draft-davie-stt/06/, work in Progress

    work page 2014

  5. [5]

    RFC 9293 (Aug 2022)

    Eddy, W.: Transmission Control Protocol (TCP). RFC 9293 (Aug 2022). https://doi.org/10.17487/RFC9293,https://www.rfc-editor.org/info/ rfc9293

    work page doi:10.17487/rfc9293 2022

  6. [6]

    com/blog/measuring-quic-vs-tcp-computational-efficiency(2021), ac- cessed: 2025-04-07

    Fastly: Measuring quic vs tcp computational efficiency.https://www.fastly. com/blog/measuring-quic-vs-tcp-computational-efficiency(2021), ac- cessed: 2025-04-07

    work page 2021

  7. [7]

    Internet- Draft draft-ietf-webtrans-http3-12, Internet Engineering Task Force (Mar 2025), https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/12/, work in Progress

    Frindell, A., Kinnear, E., Vasiliev, V.: WebTransport over HTTP/3. Internet- Draft draft-ietf-webtrans-http3-12, Internet Engineering Task Force (Mar 2025), https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/12/, work in Progress

    work page 2025

  8. [8]

    RFC 6582 (Apr 2012)

    Gurtov, A., Henderson, T., Floyd, S., Nishida, Y.: The NewReno Mod- ification to TCP’s Fast Recovery Algorithm. RFC 6582 (Apr 2012). https://doi.org/10.17487/RFC6582,https://www.rfc-editor.org/info/ rfc6582

    work page doi:10.17487/rfc6582 2012

  9. [9]

    Hertelli, S.: Comparison of Different QUIC Implementations. Tech. rep., Technical University of Munich, Germany (2022). https://doi.org/10.2313/NET-2022- 07-1_02,https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2022-07-1/ NET-2022-07-1_02.pdf, medium: PDF Publisher: Chair of Network Architectures and Services, Department of Computer Science, Technical Univ...

    work page doi:10.2313/net-2022- 2022

  10. [10]

    RFC 9002 (May 2021)

    Iyengar, J., Swett, I.: QUIC Loss Detection and Congestion Control. RFC 9002 (May 2021). https://doi.org/10.17487/RFC9002,https://www.rfc-editor.org/ info/rfc9002

    work page doi:10.17487/rfc9002 2021

  11. [11]

    RFC 9000 (May 2021)

    Iyengar, J., Thomson, M.: QUIC: A UDP-Based Multiplexed and Secure Trans- port. RFC 9000 (May 2021). https://doi.org/10.17487/RFC9000,https://www. rfc-editor.org/info/rfc9000

    work page doi:10.17487/rfc9000 2021

  12. [12]

    Communications and Network14(01), 12–22 (2022)

    Kyratzis, A.I., Cottis, P.G.: QUIC vs TCP: A Performance Evaluation over LTE with NS-3. Communications and Network14(01), 12–22 (2022). https://doi.org/10.4236/cn.2022.141002,https://www.scirp.org/journal/doi. aspx?doi=10.4236/cn.2022.141002

    work page doi:10.4236/cn.2022.141002 2022

  13. [13]

    Semester thesis, ETH Zurich (April to July 2024),https://nsg.ee.ethz.ch/ files/public/theses/2024-quic_benchmark_suite/thesis-1.pdf

    Marti, K.: Continuous benchmarking of open-source QUIC implementations. Semester thesis, ETH Zurich (April to July 2024),https://nsg.ee.ethz.ch/ files/public/theses/2024-quic_benchmark_suite/thesis-1.pdf

    work page 2024

  14. [14]

    neevek: rstun: A tcp/udp tunnel over quic written in rust.https://github.com/ neevek/rstun(2025)

    work page 2025

  15. [15]

    In: 2018 IEEE Symposium on Computers and Communications (ISCC)

    Nepomuceno, K., Oliveira, I.N.d., Aschoff, R.R., Bezerra, D., Ito, M.S., Melo, W., Sadok, D., Szabó, G.: Quic and tcp: A performance evaluation. In: 2018 IEEE Symposium on Computers and Communications (ISCC). pp. 00045–00051 (2018). https://doi.org/10.1109/ISCC.2018.8538687

    work page doi:10.1109/iscc.2018.8538687 2018

  16. [16]

    Piraux, M., Bonaventure, O.: Tunneling TCP inside QUIC. Internet- Draft draft-piraux-intarea-quic-tunnel-tcp-00, Internet Engineer- ing Task Force (Nov 2020),https://datatracker.ietf.org/doc/ draft-piraux-intarea-quic-tunnel-tcp/00/, work in Progress

    work page 2020

  17. [17]

    RFC 793 (Sep 1981)

    Postel, J.: Transmission Control Protocol. RFC 793 (Sep 1981). https://doi.org/10.17487/RFC0793,https://www.rfc-editor.org/info/rfc793

    work page doi:10.17487/rfc0793 1981

  18. [18]

    RFC 8446 (Aug 2018)

    Rescorla, E.: The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446 (Aug 2018). https://doi.org/10.17487/RFC8446,https://www.rfc-editor.org/ info/rfc8446

    work page doi:10.17487/rfc8446 2018

  19. [19]

    clap rs: clap: A full featured, fast command line argument parser for rust.https: //github.com/clap-rs/clap

    work page

  20. [20]

    quinn rs: quinn: Async-friendly quic implementation in rust.https://github.com/ quinn-rs/quinn

    work page

  21. [21]

    provides i/o, networking, scheduling, timers, ...https://github.com/tokio-rs/ tokio

    tokio rs: tokio: A runtime for writing reliable asynchronous applications with rust. provides i/o, networking, scheduling, timers, ...https://github.com/tokio-rs/ tokio

    work page

  22. [22]

    rustls: rustls: A modern tls library in rust.https://github.com/rustls/rustls

    work page