pith. sign in

arxiv: 1907.01291 · v1 · pith:5MHAMPIAnew · submitted 2019-07-02 · 💻 cs.NI

Accelerating QUIC's Connection Establishment on High-Latency Access Networks

Erik Sy , Tobias Mueller , Moritz Moennich , Hannes Federrath This is my paper

Pith reviewed 2026-05-25 10:46 UTC · model grok-4.3

classification 💻 cs.NI
keywords QUICconnection establishmentDNS proxyhigh-latency networksperformance improvementISP deploymentnetwork latency
0
0 comments X

The pith

A QuicSocks proxy colocated with ISP DNS resolvers reduces QUIC connection setup time on high-latency access networks by combining DNS resolution with the initial handshake.

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

The paper proposes a QuicSocks proxy that lets clients delegate domain name resolution to a server placed near an ISP's DNS resolver. This avoids the separate DNS round-trip that normally precedes a QUIC connection, which is costly on networks with high latency. Measurements across 474 nodes in German ISPs show that 10 percent of them would save at least 30 milliseconds per connection if the proxy shares location with the resolver. The design sticks to standard DNS and QUIC messages and accounts for NATs without needing address spoofing. A sympathetic reader would care because faster connection establishment improves the perceived speed of the web for users on mobile or other slow links.

Core claim

The authors show that by delegating the domain name resolution to a QuicSocks proxy colocated with real-world ISP-provided DNS resolvers, the overhead of QUIC's connection establishment with prior DNS lookup can be reduced on high-latency access networks. Their evaluation indicates performance gains, such as 10% of 474 sample nodes saving at least 30ms per connection. The proposal is designed for ready deployability by avoiding IP address spoofing, anticipating Network Address Translators, and using the standard DNS and QUIC protocols.

What carries the argument

The QuicSocks proxy, which receives the client's initial QUIC packet containing the domain name, resolves it via the local DNS, and then proceeds with the QUIC handshake on the client's behalf.

Load-bearing premise

That colocating the proxy with production DNS resolvers is operationally and policy-wise feasible for ISPs without introducing new problems.

What would settle it

A deployment trial where the proxy is placed with actual ISP DNS servers and real clients show no measurable reduction in connection times, or ISPs refuse colocations due to policy.

Figures

Figures reproduced from arXiv: 1907.01291 by Erik Sy, Hannes Federrath, Moritz Moennich, Tobias Mueller.

Figure 1
Figure 1. Figure 1: Schematic of QUIC’s stateless retry mechanism. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Schematic of a network packet exchange between client and server [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Protocol flow of a QUIC handshake via the proposed QuicSocks proxy, [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Network topology with colocation of DNS resolver and QuicSocks [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Cumulative distribution of the RIPE Atlas nodes in Germany using [PITH_FULL_IMAGE:figures/full_fig_p006_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Cumulative distribution of the RIPE Atlas nodes in Germany using [PITH_FULL_IMAGE:figures/full_fig_p007_7.png] view at source ↗
read the original abstract

A significant amount of connection establishments on the web require a prior domain name resolution by the client. Especially on high-latency access networks, these DNS lookups cause a significant delay on the client's connection establishment with a server. To reduce the overhead of QUIC's connection establishment with prior DNS lookup on these networks, we propose a novel QuicSocks proxy. Basically, the client delegates the domain name resolution towards the QuicSocks proxy. Our results indicate, that colocating our proxy with real-world ISP-provided DNS resolvers provides great performance gains. For example, 10% of our 474 sample nodes distributed across ISP's in Germany would save at least 30ms per QUIC connection establishment. The design of our proposal aims to be readily deployable on the Internet by avoiding IP address spoofing, anticipating Network Address Translators and using the standard DNS and QUIC protocols. In summary, our proposal fosters a faster establishment of QUIC connections for clients on high-latency access 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

1 major / 2 minor

Summary. The paper proposes QuicSocks, a proxy-based mechanism in which QUIC clients delegate DNS resolution to a proxy colocated with ISP-provided DNS resolvers. This is intended to reduce the latency of QUIC connection establishment (including the preceding DNS lookup) on high-latency access networks. The central empirical claim is that colocating the proxy yields measurable gains, with 10% of 474 sample nodes distributed across German ISPs saving at least 30 ms per connection; the design is presented as readily deployable because it uses only standard DNS and QUIC and avoids IP spoofing.

Significance. If the latency measurements accurately capture last-mile client conditions, the proposal offers a deployable, standards-compliant way to improve QUIC performance on challenged access networks without changes to endpoints or the QUIC protocol itself. The emphasis on anticipating NATs and using existing protocols is a positive aspect for real-world applicability.

major comments (1)
  1. [Results section (474 sample nodes)] Results section (paragraph reporting the 474 sample nodes and the 10% / 30 ms figure): the abstract and results present concrete performance numbers derived from latency samples to ISP DNS resolvers, yet supply no description of node selection criteria, geographic or topological placement relative to last-mile access links, measurement methodology, or statistical significance testing. This directly undermines the claim that the observed savings apply to clients on high-latency access networks, because nodes that do not traverse the contended last-mile segment would systematically underestimate real-client RTTs.
minor comments (2)
  1. [Results] The paper should include a CDF or latency distribution plot (or at minimum a table of percentiles) to allow readers to verify the 10% / 30 ms claim rather than relying on a single summary statistic.
  2. [Design] Clarify in the design section how the proxy interacts with QUIC's connection ID and 0-RTT mechanisms when the client later communicates directly with the origin server.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the detailed and constructive feedback. We address the single major comment below and will revise the manuscript to strengthen the presentation of the empirical results.

read point-by-point responses

  1. Referee: Results section (paragraph reporting the 474 sample nodes and the 10% / 30 ms figure): the abstract and results present concrete performance numbers derived from latency samples to ISP DNS resolvers, yet supply no description of node selection criteria, geographic or topological placement relative to last-mile access links, measurement methodology, or statistical significance testing. This directly undermines the claim that the observed savings apply to clients on high-latency access networks, because nodes that do not traverse the contended last-mile segment would systematically underestimate real-client RTTs.

    Authors: We agree that the current manuscript does not supply adequate detail on the measurement methodology, node selection, placement, or statistical procedures, and that this information is required to substantiate the reported latency savings for clients on high-latency access networks. In the revised version we will add a dedicated subsection to the Results section that (i) describes the node-selection process (nodes drawn from a distributed measurement platform spanning multiple German ISPs), (ii) confirms their topological placement behind last-mile access links, (iii) specifies the latency-probing method (repeated DNS and ICMP measurements to the colocated ISP resolvers), and (iv) reports the statistical procedures used to derive the 10 % / 30 ms figure together with confidence intervals. These additions will make explicit that the sampled nodes experience the access-network segment and thereby support the applicability claim. revision: yes

Circularity Check

0 steps flagged

No circularity; performance claims are direct empirical measurements

full rationale

The paper presents its key performance result (10% of 474 nodes save ≥30 ms) as the direct output of latency measurements to ISP DNS resolvers, with no equations, fitted parameters, or derivation chain that reduces the reported savings to the inputs by construction. The QuicSocks design is a protocol-level proposal whose deployability arguments rely on standard DNS/QUIC behavior rather than self-referential math or self-citation load-bearing. No steps match any of the enumerated circularity patterns; the measurement-based claim is self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The proposal rests on the assumption that standard DNS and QUIC protocol behavior remains unchanged when a proxy is inserted; no free parameters are fitted and no new physical entities beyond the proxy itself are postulated.

axioms (1)
  • domain assumption DNS and QUIC packets traverse the network without modification by middleboxes other than the proposed proxy
    The design claims compatibility with NATs and avoidance of spoofing, which presupposes that existing network elements will forward the traffic as expected.
invented entities (1)
  • QuicSocks proxy no independent evidence
    purpose: Delegate DNS resolution and initiate QUIC handshake on behalf of the client to eliminate one round-trip
    The proxy is introduced as a new component whose placement next to ISP DNS servers produces the claimed latency reduction.

pith-pipeline@v0.9.0 · 5709 in / 1400 out tokens · 31147 ms · 2026-05-25T10:46:55.115426+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

28 extracted references · 28 canonical work pages

  1. [1]

    Measuring and mitigating web performance bottlenecks in broadband access net- works,

    S. Sundaresan, N. Feamster, R. Teixeira, and N. Magharei, “Measuring and mitigating web performance bottlenecks in broadband access net- works,” in Proceedings of the 2013 conference on Internet measurement conference. ACM, 2013, pp. 213–226

    work page 2013

  2. [2]

    EYEORG: A Platform For Crowdsourcing Web Quality Of Experience Measure- ments,

    M. Varvello, J. Blackburn, D. Naylor, and K. Papagiannaki, “EYEORG: A Platform For Crowdsourcing Web Quality Of Experience Measure- ments,” ser. CoNEXT ’16. New York, NY , USA: ACM, 2016, pp. 399–412

    work page 2016

  3. [3]

    S. Souders. (2009) Velocity and the Bottom Line. [Online]. Available: http://radar.oreilly.com/2009/07/velocity-making-your-site-fast.html/

    work page 2009

  4. [4]

    Hypertext Transfer Protocol Version 3 (HTTP/3),

    M. Bishop, “Hypertext Transfer Protocol Version 3 (HTTP/3),” Inter- net Engineering Task Force, Internet-Draft draft-ietf-quic-http-20, Apr. 2019, work in Progress

    work page 2019

  5. [5]

    O’Callaghan

    J. O’Callaghan. (2019) Blue Origin To Launch Satellites For Company Battling SpaceX And Others For Space Internet Supremacy. [Online]. Available: https://tinyurl.com/y2damy3m

    work page 2019

  6. [6]

    K. Bode. (2017) OneWeb’s Low-Latency Satellite Broadband Plan Gets FCC Approval. [On- line]. Available: https://www.dslreports.com/shownews/ OneWebs-LowLatency-Satellite-Broadband-Plan-Gets-FCC-Approval-139833

    work page 2017

  7. [7]

    QUIC: A UDP-Based Multiplexed and Secure Transport,

    J. Iyengar and M. Thomson, “QUIC: A UDP-Based Multiplexed and Secure Transport,” Internet Engineering Task Force, Internet-Draft draft- ietf-quic-transport-20, Apr. 2019, work in Progress

    work page 2019

  8. [8]

    Surfing the Web quicker than QUIC via a shared Address Validation,

    E. Sy, “Surfing the Web quicker than QUIC via a shared Address Validation,” 2019

    work page 2019

  9. [9]

    The QUIC Transport Protocol: Design and Internet-Scale Deployment,

    A. Langley, A. Riddoch, A. Wilk, A. Vicente, C. Krasic, D. Zhang, F. Yang, F. Kouranov, I. Swett, J. Iyengar et al. , “The QUIC Transport Protocol: Design and Internet-Scale Deployment,” in Proceedings of the Conference of the ACM Special Interest Group on Data Communication . ACM, 2017, pp. 183–196

    work page 2017

  10. [10]

    Is it still possible to extend TCP?

    M. Honda, Y . Nishida, C. Raiciu, A. Greenhalgh, M. Handley, and H. Tokuda, “Is it still possible to extend TCP?” ser. SIGCOMM ’11. ACM, 2011, pp. 181–194

    work page 2011

  11. [11]

    An experimental study of home gateway characteristics,

    S. H ¨at¨onen, A. Nyrhinen, L. Eggert, S. Strowes, P. Sarolahti, and M. Kojo, “An experimental study of home gateway characteristics,” ser. SIGCOMM ’10. ACM, 2010, pp. 260–266

    work page 2010

  12. [12]

    SOCKS Protocol Version 5,

    M. D. Leech, “SOCKS Protocol Version 5,” RFC 1928, Mar. 1996

    work page 1928

  13. [13]

    A SOCKS-based IPv6/IPv4 Gateway Mechanism,

    H. Kitamura, “A SOCKS-based IPv6/IPv4 Gateway Mechanism,” RFC 3089, Apr. 2001

    work page 2001

  14. [14]

    Tor: The second- generation onion router,

    R. Dingledine, N. Mathewson, and P. Syverson, “Tor: The second- generation onion router,” Naval Research Lab Washington DC, Tech. Rep., 2004

    work page 2004

  15. [15]

    DNS performance and the effectiveness of caching,

    J. Jung, E. Sit, H. Balakrishnan, and R. Morris, “DNS performance and the effectiveness of caching,” IEEE/ACM Transactions on networking , vol. 10, no. 5, pp. 589–603, 2002

    work page 2002

  16. [16]

    En- hanced Performance for the encrypted Web through TLS Resumption across Hostnames,

    E. Sy, M. Moennich, T. Mueller, H. Federrath, and M. Fischer, “En- hanced Performance for the encrypted Web through TLS Resumption across Hostnames,” 2019

    work page 2019

  17. [17]

    Connection-oriented DNS to improve privacy and security,

    L. Zhu, Z. Hu, J. Heidemann, D. Wessels, A. Mankin, and N. Somaiya, “Connection-oriented DNS to improve privacy and security,” in 2015 IEEE symposium on security and privacy . IEEE, 2015, pp. 171–186

    work page 2015

  18. [18]

    Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,

    D. Senie and P. Ferguson, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” RFC 2827, May 2000

    work page 2000

  19. [19]

    Broadband Internet Performance: A View from the Gateway,

    S. Sundaresan, W. de Donato, N. Feamster, R. Teixeira, S. Crawford, and A. Pescap `e, “Broadband Internet Performance: A View from the Gateway,” ser. SIGCOMM ’11. New York, NY , USA: ACM, 2011, pp. 134–145

    work page 2011

  20. [20]

    (2018) USA Mobile Network Experience Report January 2019

    OpenSignal. (2018) USA Mobile Network Experience Report January 2019 . [Online]. Available: https://www.opensignal.com/reports/2019/ 01/usa/mobile-network-experience

    work page 2018

  21. [21]

    (2019) RIPE Atlas – Internet measurement network

    Reseaux IP Europeens Network Coordination Centre. (2019) RIPE Atlas – Internet measurement network. [Online]. Available: https: //atlas.ripe.net/

    work page 2019

  22. [22]

    Host Anycasting Service,

    W. Milliken, T. Mendez, and D. C. Partridge, “Host Anycasting Service,” RFC 1546, Nov. 1993

    work page 1993

  23. [23]

    (2019) Chrome Lite Pages - For a faster, leaner loading experience

    Greenstein, Ben and Gao, Nancy. (2019) Chrome Lite Pages - For a faster, leaner loading experience. [Online]. Available: http://s3.amazonaws.com/alexa-static/top-1m.csv.zip

    work page 2019

  24. [24]

    On the Fly TCP Acceleration with Miniproxy,

    G. Siracusano, R. Bifulco, S. Kuenzer, S. Salsano, N. B. Melazzi, and F. Huici, “On the Fly TCP Acceleration with Miniproxy,” inProceedings of the 2016 Workshop on Hot Topics in Middleboxes and Network Function Virtualization, ser. HotMIddlebox ’16. New York, NY , USA: ACM, 2016, pp. 44–49

    work page 2016

  25. [25]

    Enhanced Performance and Privacy for TLS over TCP Fast Open,

    E. Sy, T. Mueller, C. Burkert, H. Federrath, and M. Fischer, “Enhanced Performance and Privacy for TLS over TCP Fast Open,” 2019

    work page 2019

  26. [26]

    ASAP: A Low-latency Transport Layer,

    W. Zhou, Q. Li, M. Caesar, and P. B. Godfrey, “ASAP: A Low-latency Transport Layer,” ser. CoNEXT ’11. New York, NY , USA: ACM, 2011, pp. 20:1–20:12

    work page 2011

  27. [27]

    Low Latency via Redundancy,

    A. Vulimiri, P. B. Godfrey, R. Mittal, J. Sherry, S. Ratnasamy, and S. Shenker, “Low Latency via Redundancy,” in Proceedings of the Ninth ACM Conference on Emerging Networking Experiments and Technologies, ser. CoNEXT ’13. New York, NY , USA: ACM, 2013, pp. 283–294

    work page 2013

  28. [28]

    DNS Queries over HTTPS (DoH),

    P. E. Hoffman and P. McManus, “DNS Queries over HTTPS (DoH),” RFC 8484, Oct. 2018

    work page 2018