Pith. sign in

REVIEW 3 major objections 7 minor 80 references

Hermes: A General-Purpose Proxy-Enabled Networking Architecture

T0 review · 3 major / 7 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read Hermes is a proxy overlay that claims to take networking responsibilities away from applications and services, delivering compatibility, reliability, and policy-based routing with overhead typically under 2 ms per proxy pair.

desk verdict A real systems paper with working prototypes, but the abstract sells stronger results than the body supports; the intermittent-link case is the weakest and needs an honest fix. read the letter →

arxiv 2411.13668 v3 pith:2JN3P6NY submitted 2024-11-20 cs.NI cs.PF

Behrooz Farkiani , Fan Liu , Ke Yang , John DeHart , Jyoti Parwatikar , Patrick Crowley This is my paper · ORCID
classification cs.NIcs.PF
keywords overlaynetworkingHTTPtunnelingproxyarchitecturepolicy-basedroutingNamedDatareliabilityinunstablenetworksbackwardcompatibilitycontrolplane
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

Hermes is a proposed general-purpose networking architecture built as an overlay of dynamically reconfigurable proxies. Its central claim is that networking responsibilities now baked into applications and services can be delegated to these proxies, which use HTTP tunneling and HTTP-header-based semantic routing to provide end-to-end traffic control, backward compatibility, reliability in unstable networks, and a substrate for future architectures. The paper supports the claim by prototyping the overlay and evaluating it in four use cases: legacy UDP video streaming, downloads over intermittent links, policy-based IP routing with movable endpoints, and NDN transport. If the claim holds, service providers can extend their control to end-user devices without modifying applications, and the internet gains an adaptable narrow-waist layer built on HTTP rather than a clean-slate redesign. The measured overhead is modest, typically under 2 ms per proxy pair traversal in an isolated collocated setup, with connection pooling and multiplexing amortizing setup cost at scale.

What carries the argument

The load-bearing mechanism is the overlay of dependent and standalone proxies coordinated by a logically centralized control plane. Dependent proxies sit at or near end hosts and mediate all traffic entering or leaving apps; standalone proxies act as HTTP-level software routers. HTTP is the unifying substrate: proxies tunnel UDP, TCP, or IP packets inside HTTP using CONNECT-family methods, append custom headers that the overlay uses for naming, policy, and routing decisions, and can defer header processing to later hops. Assisting components (a tunnel device for IP-in-UDP encapsulation and split tunneling, a policy engine for authorization) extend what the proxies can do without changing the proxy core. This combination lets the architecture treat forwarding, reliability, compatibility, and policy as proxy configuration rather than application logic.

What would settle it

Run the intermittent-link experiment with a fresh link on/off schedule that the Table XIII parameters were not tuned to, and require the control plane to derive retry settings automatically; if download success falls well below the demonstrated 100% without manual re-tuning, the claim that the overlay provides a general reliability benefit over direct TCP is unsupported.

Watch

Extended reading notes

Core claim

The paper's discovery is that the four challenges—traffic management, backward compatibility, data-plane security and privacy models, and adaptable communication layers—can be addressed together by a single overlay architecture rather than by separate point solutions. Hermes assigns each app or service a nearby "dependent" proxy and arranges those proxies into a reconfigurable overlay; traffic is encapsulated over HTTP (via CONNECT, CONNECT-UDP, and CONNECT-IP/MASQUE mechanisms), and custom HTTP headers carry user identity, address-space, and routing semantics that proxies process hop by hop. The prototype measurements show that this design can eliminate macroblock errors in a UDP video stream under 1% loss, raise download success from 0% to 100% across three intermittent links, move a user's ingress and personal server across oceans while keeping all pings answered, and carry NDN traffic with 0-12% transfer-time overhead while adding load balancing and hiding UDP ports. The cost of the HTTP layer is presented as typically under 2 ms per proxy pair traversal in a collocated measurement, and as negative at scale because connection pooling and multiplexing reduce end-to-end latency under concurrency.

Load-bearing premise

The general-purpose reliability and adaptivity claims assume that proxy retry and reconfiguration parameters can be set for real conditions in a principled way, because the paper's own reliability demonstration uses retry timings that its discussion concedes appear fine-tuned to the specific intermittent-link pattern.

Editorial extensions

If this is right

  • Client and server software can stay unchanged while the overlay upgrades transport behavior, for example restoring lossless video over a lossy link by tunneling UDP over HTTP/TCP.
  • Networks with no stable end-to-end path can still complete TCP downloads when proxies decompose the path into per-hop connections and retry according to control-plane-specified parameters.
  • Organizations can enforce end-to-end routing policy by user identity, move ingress points or servers in under ten seconds through configuration changes alone, and give different users different physical destinations for the same IP address.
  • Experimental architectures such as NDN can run over the existing internet without exposing UDP ports, mapping namespaces to overlay address spaces and getting reliability and load balancing from the overlay.
  • HTTP tunneling overhead stays below roughly 2 ms per proxy pair in the collocated setup, and connection pooling and multiplexing under up to 1,000 concurrent requests can make the proxied path faster than a direct connection.

Reading between the lines

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

  • If the same reconfigurable-proxy substrate were paired with an automatic control loop that observes link quality and adjusts per-hop transport (TCP versus QUIC) and retry parameters, the reliability benefit would generalise beyond the hand-tuned demonstration; the paper motivates this but does not implement it.
  • The sub-2 ms overhead figure was measured in an isolated collocated network; over real internet paths with multiple TLS-protected hops and queuing, the end-to-end extra latency could plausibly be larger, which would matter for latency-sensitive services.
  • The dedicated address-space mechanism implies a clean split between naming and location that could be pushed further: proxies could resolve names locally or through other proxies without global DNS updates, a capability the paper describes and the NDN use case exercises.
  • A proxy overlay this flexible could act as a deployment substrate for other clean-slate or ICN architectures, since the NDN result suggests the mapping from architecture-level names to overlay address spaces is generic rather than NDN-specific.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 7 minor

Summary. The paper presents Hermes, an overlay networking architecture composed of reconfigurable HTTP proxies managed by a control plane. The authors argue that delegating networking responsibilities from applications and services to proxies at end-user devices enables end-to-end traffic management, backward compatibility via tunneling and protocol translation, improved reliability through proxy-side retry logic, policy-based L3 routing, and a communication substrate for experimental architectures such as NDN. A prototype built on Envoy, OPA, custom tunnel components, and mobile clients is evaluated in four use cases: UDP video streaming over a lossy link, file download over three intermittent links, IP tunneling with dynamic ingress relocation, and NDN traffic over a two-domain overlay. The paper reports that the overlay eliminates video errors, raises download success from 0% to 100% in the intermittent scenario, enables sub-10-second reconfiguration, and transfers NDN data with up to 12% overhead.

Significance. If the central claims are substantiated, Hermes would be a useful contribution to the overlay-networking literature: it extends proxy-based traffic management to end-user devices in a general-purpose, reconfigurable way and provides a practical path for deploying experimental architectures over the current Internet. The paper's strengths are its concrete prototype, the open-source release, and the explicit acknowledgment of limitations (e.g., Section III-B's concession that the retry parameters may appear fine-tuned). However, the current evaluation does not support all of the abstract's quantitative claims, and the reliability result is best read as a tuned feasibility demonstration rather than a general-purpose result.

major comments (3)
  1. [Abstract / Section III] The abstract states that Hermes' overhead is 'typically under 2 ms per proxy pair traversal' and that with up to 1,000 concurrent requests proxies can reduce end-to-end latency via connection pooling and multiplexing. No section of the body reports an experiment with 1,000 concurrent requests, and the only latency measurements (Table III for the IP use case and Table IV for NDN) do not report per-proxy-pair traversal overhead under 2 ms. This is load-bearing because the 'modest overhead' claim is a key part of the paper's central argument that Hermes is a practical general-purpose architecture. Please add the missing measurement or remove these quantitative claims from the abstract.
  2. [Section III-B] The 100% success ratio in the Intermittent use case is obtained with retry parameters (Table XIII) that are manually set for the specific three-link intermittent pattern, as the paper itself concedes in the Discussion: 'wget and overlay proxies retry parameters (Table XIII) might look like to be fine-tuned for this particular example.' The subsequent argument that 'assisting components' and the control plane can update these parameters is not evaluated: no algorithm, adaptation rule, or experiment is provided. The evaluation therefore demonstrates that a hand-tuned retry configuration can mask the simulated disconnections, not that Hermes provides a general-purpose reliability benefit. Please either implement and evaluate automatic parameter derivation or explicitly limit the reliability claim to a feasibility demonstration.
  3. [Section III-B.3] In the end-to-end secure 'Overlay w/CONN' scenario, the success ratios are only 80% (1MB) and 32.5% (5MB) because wget aborts with 'Unable to establish SSL connection' before exhausting its retries. The paper attributes this to a wget bug, but the scenario is precisely the one in which the client's networking responsibility has been delegated to the proxies; the interaction between the client's retry behavior and the proxy's retry policy is part of the system under test. As presented, the reliability claim holds only for the hop-by-hop TLS mode, which requires trusting the overlay proxies. Please analyze this interaction and either adapt the client or proxy configuration or report the secure-mode reliability as an open issue.
minor comments (7)
  1. [Section III-D] The contribution list and Section III-D.1 claim 'load balancing' between NDN namespace servers, but Table IV reports only transfer time; no metric or experiment demonstrates that the overlay actually distributes load across the servers. Please add a load-balancing evaluation or remove the term from the claimed contributions.
  2. [Section III-C.3] The paper sets 'max stream duration' to 3 seconds 'to prevent Envoy crashes'; this workaround should be justified, as it bounds connection lifetime and may affect the reported RTT values in Figure 6d.
  3. [Section II-D.6] The multi-domain discovery and control-plane mechanisms are left as 'public directories combined with out-of-band communication'; no prototype or evaluation of inter-domain operation is presented, so the multi-domain claims in Sections II-C and III-D rest on a design sketch rather than a demonstrated mechanism.
  4. [Section III (all use cases)] No statistical significance tests or confidence intervals are reported; given the small number of runs (e.g., 20 batches in Section III-B, 30 iterations in Section III-A) and the large standard deviations in Table II, the robustness of the reported differences is unclear.
  5. [Table III] The US 'Latency' row has a standard deviation (37.85 ms) larger than its mean (21.71 ms), and the three latency columns appear to be measured under different conditions; please clarify how these values were collected and why the variance is so high.
  6. [Section IV] The claim that Hermes is 'the first overlay of proxies that can be applied to general-purpose use cases' is a strong novelty statement; it would benefit from a more careful comparison with earlier general-purpose overlay networks (e.g., RON or the overlays surveyed in reference [1]).
  7. [Throughout] There are several typographical and wording issues, including 'has advantageous compared to' in Section I Observation 3, 'Experiements' in the Table VII caption, and the awkward formatting of Figure 6d's y-axis labels; these should be corrected.

Circularity Check

1 steps flagged · score 4.0 of 10

One partial circularity: the intermittent-link reliability result is a hand-tuned demonstration rather than an independent prediction; the other use cases stand on their own.

  1. fitted input called prediction [Section III-B (Discussion) and Table XIII; abstract reliability claim]
    ""overlay proxies parameters can be tuned to achieve 100% successful delivery" (Section II-A); "It is noteworthy to mention that wget and overlay proxies retry parameters (Table XIII) might look like to be fine-tuned for this particular example." (Section III-B Discussion)"

    The 100% success ratio in the intermittent use case is not an independent prediction; it is the direct consequence of the retry policy chosen for the exact failure pattern (three links each up for 1 s, never simultaneously; wget tries=10, timeout=60, waitretry=20; Envoy per-try timeout=25s, num retries=2). The authors concede the parameters look fine-tuned for this particular example, and the claimed generalization to arbitrary unstable networks is deferred to hypothetical assisting components and controller logic that are not evaluated. Thus the reliability headline reduces, for this use case, to the configured inputs rather than to a measured property of the general architecture. The other use cases provide independent evidence, so the circularity is partial.

full rationale

The only material circularity is the Section III-B reliability demonstration, where the success metric is determined by retry parameters the paper itself admits are fine-tuned for the example. I still weight the overall score at 4 rather than 6 because the central architecture claim is not exhausted by this one use case: the video use case compares overlay HTTP tunneling against direct UDP and shows the expected TCP-vs-UDP reliability difference while preserving unmodified client and server; the IP use case measures real RTT changes before and after reconfiguration; the NDN use case measures transfer time against a direct NDN connection. These are empirical comparisons with independent content. The self-citations in the paper (e.g., [38] for TCP failure over intermittent links, [31] for the service mesh survey) are not load-bearing: the direct-intermittent failure is reproduced in this paper's own Base-Intermittent measurements, and the service mesh comparison is background. The paper's explicit Discussion admission is a limitation on generality, not a hidden circular step; but the reliability 'improvement' itself is a hand-tuned demonstration, so a modest partial-circularity score is appropriate.

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

The central claim rests on several domain assumptions about HTTP tunnel viability, user adoption, and emulation fidelity. The main free parameters are the retry settings and a timeout workaround, which the paper admits are tuned. No new physical entities are introduced.

free parameters (2)
  • Intermittent use case retry parameters = wget: tries=10, waitretry=20, timeout=60, continue, retry-connrefused, retry-on-http-error=503; Envoy: retry on 5xx…
    Manually chosen to make file downloads succeed across the synthetic intermittent links; the paper admits they 'might look like to be fine-tuned for this particular example' (Section III-B Discussion).
  • IP use case max stream duration = 3 seconds
    Set to 3s to prevent Envoy crashes during the latency experiment (Section III-C Implementation), an ad hoc adjustment.
assumptions (4)
  • domain assumption HTTP is extensible and can carry virtually any type of traffic (Observation 4).
    The entire architecture depends on HTTP tunneling (CONNECT, CONNECT-UDP, CONNECT-IP) being viable across the internet; middleboxes can interfere in practice.
  • domain assumption End users will accept and run a dependent proxy on their devices.
    Hermes mandates at least one dependent proxy on the end-user side (Section II-B); adoption depends on user willingness and trust.
  • domain assumption The tc-based emulation of link loss and intermittent connectivity faithfully represents real unstable networks.
    All reliability and video results come from controlled tc setups, not real-world lossy links (Section III).
  • domain assumption A control plane can reconfigure proxies quickly enough (hot restart) to adapt to changing conditions.
    The IP use case update process relies on hot restart completing in under 10 seconds, as described in Section III-C.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Hermes: A General-Purpose Proxy-Enabled Networking Architecture." pith.science (2026). https://pith.science/paper/2JN3P6NY

@misc{pith2026241113668,
  author       = {Pith},
  title        = {Pith review of: Hermes: A General-Purpose Proxy-Enabled Networking Architecture},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2JN3P6NY}},
  note         = {Machine review of arXiv:2411.13668}
}
read the original abstract

We introduce Hermes, a general-purpose networking architecture that aims to improve service delivery over the Internet. Hermes delegates networking responsibilities from applications and services to proxies and is designed as a portable, adaptable solution to four fundamental challenges of efficient service delivery over the Internet: end-to-end traffic management, backward compatibility, data-plane security and privacy models, and adaptable communication layers. The design centers on an overlay of reconfigurable proxies and HTTP tunneling and proxying techniques, utilizing assisting components to extend proxy functionality when needed. Through prototyping and emulation, we demonstrate that Hermes improves key performance metrics across multiple use cases: it provides backward compatibility through protocol translation and tunneling, improves reliability by delegating retry logic to proxies, enables unified policy-based Layer 3 routing across network segments, and serves as an efficient substrate for future architectures like NDN, facilitating their operation over the Internet. Beyond evaluating Hermes across various use cases, we measured the overhead of Hermes' HTTP tunneling and proxying mechanisms and found it to be modest, typically under 2 ms per proxy pair traversal in an isolated collocated setup. Although the HTTP proxying and tunneling techniques used by Hermes increase single-connection processing overhead, we also show that, with up to 1,000 concurrent requests, proxies can amortize connection setup time and reduce end-to-end latency by utilizing connection pooling and multiplexing.

Figures

Figures reproduced from arXiv: 2411.13668 by the authors.

Figure 1
Figure 1. Different proxy configurations Monitoring Overlay controller Infra controller Config DB DP SaP Data Control [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. Control plane components [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Deployment example. Proxies are in green. FutureNet nodes are in black. [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Video use case topology. Overlay is above. [PITH_FULL_IMAGE:figures/full_fig_p011_4.png]
Figure 5
Figure 5. Figure 5: Intermittent use case topology. Overlay is above. [PITH_FULL_IMAGE:figures/full_fig_p012_5.png]
Figure 6
Figure 6. Figure 6: The overall overlay update process and performance evaluation. [PITH_FULL_IMAGE:figures/full_fig_p014_6.png]
Figure 7
Figure 7. Figure 7: The end-user used ndncatchunks [63] to request con [PITH_FULL_IMAGE:figures/full_fig_p016_7.png]
Figure 8
Figure 8. Figure 8: The Hermes Android mobile client [PITH_FULL_IMAGE:figures/full_fig_p021_8.png]
Figure 9
Figure 9. Figure 9: The Hermes iOS mobile client. TABLE VII: File sizes used in the experiements Use case File name Size of the downloaded files on disk (bytes) Video 1 minute [54] 5736233 2 minutes [54] 11688214 Intermittent 1 MB [75] 1090352 5 MB [75] 5497060 NDN 0KB 0 1MB [75] 1090352 …

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

80 extracted references · 74 canonical work pages

  1. [1]

    Overlay Networks and the Future of the Internet,

    D. Clark, B. Lehr, S. Bauer, P. Faratin, R. Sami, and J. Wroclawski, “Overlay Networks and the Future of the Internet,” Communications and Strategies, vol. 63, p. 109, 2006, publisher: Citeseer

    work page 2006

  2. [2]

    Enabling a permanent revolution in internet architecture,

    J. McCauley, Y . Harchol, A. Panda, B. Raghavan, and S. Shenker, “Enabling a permanent revolution in internet architecture,” in Proceedings of the ACM Special Interest Group on Data Communication, ser. SIGCOMM ’19. New York, NY , USA: Association for Computing Machinery, Aug. 2019, pp. 1–14. [Online]. Available: https://dl.acm.org/doi/10.1145/3341302.3342075

    arXiv 2019

  3. [3]

    Revitalizing the public internet by making it extensible,

    H. Balakrishnan, S. Banerjee, I. Cidon, D. Culler, D. Estrin, E. Katz-Bassett, A. Krishnamurthy, M. McCauley, N. McKeown, A. Panda, S. Ratnasamy, J. Rexford, M. Schapira, S. Shenker, I. Stoica, D. Tennenhouse, A. Vahdat, and E. Zegura, “Revitalizing the public internet by making it extensible,” SIGCOMM Comput. Commun. Rev., vol. 51, no. 2, pp. 18–24, May ...

    work page arXiv 2021

  4. [5]

    Perrig, P

    A. Perrig, P. Szalachowski, R. M. Reischuk, and L. Chuat, SCION: A Secure Internet Architecture , ser. Information Security and Cryptography. Cham: Springer International Publishing, 2017. [Online]. Available: http://link.springer.com/10.1007/978-3-319-67080-5

    work page doi:10.1007/978-3-319-67080-5 2017

  5. [6]

    Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations,

    J. Griner, J. Border, M. Kojo, Z. D. Shelby, and G. Montenegro, “Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations,” Internet Engineering Task Force, Request for Comments RFC 3135, Jun. 2001. [Online]. Available: https://datatracker.ietf.org/ doc/rfc3135

    work page 2001

  6. [7]

    Tor: the second- generation onion router,

    R. Dingledine, N. Mathewson, and P. Syverson, “Tor: the second- generation onion router,” in Proceedings of the 13th conference on USENIX Security Symposium - Volume 13 , ser. SSYM’04. USA: USENIX Association, Aug. 2004, p. 21

    work page 2004

  7. [8]

    The Akamai network: a platform for high-performance internet applications,

    E. Nygren, R. K. Sitaraman, and J. Sun, “The Akamai network: a platform for high-performance internet applications,” SIGOPS Oper. Syst. Rev. , vol. 44, no. 3, pp. 2–19, Aug. 2010. [Online]. Available: https://doi.org/10.1145/1842733.1842736

    work page arXiv 2010

  8. [9]

    Performance Benchmarking of the QUIC Transport Protocol,

    B. V . Da Cunha, X. Li, W. Wilson, and K. Harfoush, “Performance Benchmarking of the QUIC Transport Protocol,” in 2023 IEEE 20th Consumer Communications & Networking Conference (CCNC) , Jan. 2023, pp. 206–212, iSSN: 2331-9860. [Online]. Available: https://ieeexplore.ieee.org/document/10060785

    work page arXiv 2023

Show all 80 references
  1. [10]

    QUIC is not Quick Enough over Fast Internet,

    X. Zhang, S. Jin, Y . He, A. Hassan, Z. M. Mao, F. Qian, and Z.-L. Zhang, “QUIC is not Quick Enough over Fast Internet,” in Proceedings of the ACM on Web Conference 2024 , ser. WWW ’24. New York, NY , USA: Association for Computing Machinery, May 2024, pp. 2713–2722

    2024

  2. [11]

    Routing in intermittently connected mobile ad hoc networks and delay tolerant networks: overview and challenges,

    Z. Zhang, “Routing in intermittently connected mobile ad hoc networks and delay tolerant networks: overview and challenges,” IEEE Commun. Surv. Tutorials , vol. 8, no. 1, pp. 24–37, 2006. [Online]. Available: http://ieeexplore.ieee.org/document/4116780/

    2006

  3. [12]

    Named data networking,

    L. Zhang, A. Afanasyev, J. Burke, V . Jacobson, k. claffy, P. Crowley, C. Papadopoulos, L. Wang, and B. Zhang, “Named data networking,” SIGCOMM Comput. Commun. Rev. , vol. 44, no. 3, pp. 66–73, Jul

  4. [13]

    Lightweight Security Scheme for MQTT/MQTT-SN Protocol,

    O. Sadio, I. Ngom, and C. Lishou, “Lightweight Security Scheme for MQTT/MQTT-SN Protocol,” in 2019 Sixth International Conference on Internet of Things: Systems, Management and Security (IOTSMS) , Oct. 2019, pp. 119–123. [Online]. Available: https://ieeexplore.ieee.org/ abstra...

    2019

  5. [14]

    A Robust Selective Encryption Scheme for H.265/HEVC Video,

    C. Chen, X. Wang, G. Liu, and G. Huang, “A Robust Selective Encryption Scheme for H.265/HEVC Video,” IEEE Access , vol. 11, pp. 17 252–17 264, 2023, conference Name: IEEE Access. [Online]. Available: https://ieeexplore.ieee.org/document/9903590

    2023

  6. [15]

    Cross-layer design: a survey and the road ahead,

    V . Srivastava and M. Motani, “Cross-layer design: a survey and the road ahead,” IEEE Communications Magazine, vol. 43, no. 12, pp. 112– 119, Dec. 2005, conference Name: IEEE Communications Magazine. [Online]. Available: https://ieeexplore.ieee.org/document/1561928

    2005

  7. [16]

    Schumann, T

    L. Schumann, T. V . Doan, T. Shreedhar, R. Mok, and V . Bajpai. (2022, Jan.) Impact of Evolving Protocols and COVID-19 on Internet Traffic Shares. [Online]. Available: http://arxiv.org/abs/2201.00142

    2022 arXiv

  8. [17]

    A Decade Long View of Internet Traffic Composition in Japan,

    I. Tsareva, T. V . Doan, and V . Bajpai, “A Decade Long View of Internet Traffic Composition in Japan,” in 2023 IFIP Networking Conference (IFIP Networking) , Jun. 2023, pp. 1–9, iSSN: 1861-2288. [Online]. Available: https://ieeexplore.ieee.org/document/10186393

    2023

  9. [18]

    Accessed: 2024-01-01

    (2024) Cloudflare Radar. Accessed: 2024-01-01. [Online]. Available: https://radar.cloudflare.com/traffic?dateStart=2023-01-01& dateEnd=2023-12-31

    2024

  10. [19]

    HTTP as the narrow waist of the future internet,

    L. Popa, A. Ghodsi, and I. Stoica, “HTTP as the narrow waist of the future internet,” in Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks , ser. Hotnets-IX. New York, NY , USA: Association for Computing Machinery, Oct. 2010, pp. 1–6. [Online]. Available: h...

    2010

  11. [20]

    Proxying UDP in HTTP,

    D. Schinazi, “Proxying UDP in HTTP,” Internet Engineering Task Force, Request for Comments RFC 9298, Aug. 2022, num Pages: 16. [Online]. Available: https://datatracker.ietf.org/doc/rfc9298

    2022

  12. [21]

    Proxying IP in HTTP,

    T. Pauly, D. Schinazi, A. Chernyakhovsky, M. K ¨uhlewind, and M. Westerlund, “Proxying IP in HTTP,” Internet Engineering Task Force, Request for Comments RFC 9484, Oct. 2023, num Pages: 37. [Online]. Available: https://datatracker.ietf.org/doc/rfc9484

    2023

  13. [22]

    Proxying Ethernet in HTTP,

    A. Sede ˜no, “Proxying Ethernet in HTTP,” Internet Engineering Task Force, Internet Draft draft-ietf-masque-connect-ethernet-04, Jul. 2024, num Pages: 16. [Online]. Available: https://datatracker.ietf.org/doc/ draft-ietf-masque-connect-ethernet-04

    2024

  14. [23]

    The MASQUE Proxy,

    D. Schinazi, “The MASQUE Proxy,” Internet Engineering Task Force, Internet Draft draft-schinazi-masque-proxy-04, Aug. 2024, num Pages: 7. [Online]. Available: https://datatracker.ietf.org/doc/ draft-schinazi-masque-proxy

    2024

  15. [24]

    Accessed: 2024-08-21

    (2024) How Cloudflare works | Cloudflare Fundamentals docs. Accessed: 2024-08-21. [Online]. Available: https://developers.cloudflare. com/fundamentals/concepts/how-cloudflare-works/

    2024

  16. [25]

    PEP-DNA: A Performance Enhancing Proxy for Deploying Network Architectures,

    K. Ciko, M. Welzl, and P. Teymoori, “PEP-DNA: A Performance Enhancing Proxy for Deploying Network Architectures,” in 2021 IEEE 29th International Conference on Network Protocols (ICNP) , Nov. 2021, pp. 1–6, iSSN: 2643-3303. [Online]. Available: https: //ieeexplore.ieee.org/doc...

    2021

  17. [26]

    iCloud Private Relay Overview,

    “iCloud Private Relay Overview,” Apple, Tech. Rep., Dec. 2021, num Pages: 11. [Online]. Available: https://www.apple.com/icloud/ docs/iCloud Private Relay Overview Dec2021.pdf

    2021

  18. [27]

    Accessed: 2024-09-24

    (2024) Istio documentation. Accessed: 2024-09-24. [Online]. Available: https://istio.io/latest/docs/

    2024

  19. [28]

    Accessed: 2024-08-21

    (2024) Service Mesh on Consul | Consul | HashiCorp Developer. Accessed: 2024-08-21. [Online]. Available: https://developer.hashicorp. com/consul/docs/connect

    2024

  20. [29]

    Canal Mesh: A Cloud-Scale Sidecar-Free Multi-Tenant Service Mesh Architecture,

    E. Song, Y . Song, C. Lu, T. Pan, S. Zhang, J. Lu, J. Zhao, X. Wang, X. Wu, M. Gao, Z. Li, Z. Fang, B. Lyu, P. Zhang, R. Wen, L. Yi, Z. Zong, and S. Zhu, “Canal Mesh: A Cloud-Scale Sidecar-Free Multi-Tenant Service Mesh Architecture,” in Proceedings of the ACM SIGCOMM 2024 Con...

    2024

  21. [30]

    Howard, E

    J. Howard, E. J. Jackson, Y . Kohavi, I. Levine, J. Pettit, and L. Sun. (2024) Introducing Ambient Mesh. Accessed: 2024-01-01. [Online]. Available: https://istio.io/latest/blog/2022/introducing-ambient-mesh/

    2024

  22. [31]

    Service Mesh: Architectures, Applications, and Implementations,

    B. Farkiani and R. Jain, “Service Mesh: Architectures, Applications, and Implementations,” Tech. Rep., May 2024, arXiv:2405.13333 [cs]. [Online]. Available: http://arxiv.org/abs/2405.13333

    2024 arXiv

  23. [32]

    Design Patterns for Container-based Distributed Systems,

    B. Burns and D. Oppenheimer, “Design Patterns for Container-based Distributed Systems,” in 8th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 16) . Denver, CO: USENIX Association, Jun. 2016. [Online]. Available: https://www.usenix.org/conference/ hotcloud16/worksho...

    2016

  24. [33]

    Service Mesh: Challenges, State of the Art, and Future Research Opportunities,

    W. Li, Y . Lemieux, J. Gao, Z. Zhao, and Y . Han, “Service Mesh: Challenges, State of the Art, and Future Research Opportunities,” in 2019 IEEE International Conference on Service-Oriented System Engi- neering (SOSE), Apr. 2019, pp. 122–1225, iSSN: 2642-6587. [Online]. Availab...

    2019

  25. [34]

    Leveraging Service Meshes as a New Network Layer,

    S. Ashok, P. B. Godfrey, and R. Mittal, “Leveraging Service Meshes as a New Network Layer,” in Proceedings of the 20th ACM Workshop on Hot Topics in Networks , ser. HotNets ’21. New York, NY , USA: Association for Computing Machinery, Nov. 2021, pp. 229–236. [Online]. Availabl...

    2021

  26. [35]

    Accessed: 2024-09-

    (2024) Your First Service | OpenZiti. Accessed: 2024-09-

    2024

  27. [36]

    Intermittently- connected IoT devices: Experiments with an NDN-DTN architecture,

    C.-A. Sarros, V . Demiroglou, and V . Tsaoussidis, “Intermittently- connected IoT devices: Experiments with an NDN-DTN architecture,” JOURNAL SUBMISSION 20 in 2021 IEEE 18th Annual Consumer Communications & Networking Conference (CCNC). Las Vegas, NV , USA: IEEE, Jan. 2021, pp. 1–9

    2021

  28. [37]

    Available: https://openziti.io/docs/learn/core-concepts/ zero-trust-models/overview

    [Online]. Available: https://openziti.io/docs/learn/core-concepts/ zero-trust-models/overview

  29. [38]

    Mitigating Intermittent Links With Name-Based Networking,

    B. Farkiani, J. DeHart, J. Parwatikar, and P. Crowley, “Mitigating Intermittent Links With Name-Based Networking,” in Proceedings of the 10th ACM Conference on Information-Centric Networking , ser. ACM ICN ’23. New York, NY , USA: Association for Computing Machinery, Oct. 2023...

    2023

  30. [39]

    Supporting Delay Tolerant Networking: A Comparative Study of Epidemic Routing and NDN,

    T. Li, Z. Kong, and L. Zhang, “Supporting Delay Tolerant Networking: A Comparative Study of Epidemic Routing and NDN,” in 2020 IEEE International Conference on Communications Workshops (ICC Workshops). Dublin, Ireland: IEEE, Jun. 2020, pp. 1–6. [Online]. Available: https://iee...

    2020

  31. [40]

    A remotely accessible network processor-based router for network experimentation,

    C. Wiseman, J. Turner, M. Becchi, P. Crowley, J. DeHart, M. Haitjema, S. James, F. Kuhns, J. Lu, J. Parwatikar, R. Patney, M. Wilson, K. Wong, and D. Zar, “A remotely accessible network processor-based router for network experimentation,” in Proceedings of the 4th ACM/IEEE Sym...

    2008

  32. [41]

    HTTP Semantics,

    R. T. Fielding, M. Nottingham, and J. Reschke, “HTTP Semantics,” Internet Engineering Task Force, Request for Comments RFC 9110, Jun. 2022, num Pages: 194. [Online]. Available: https: //datatracker.ietf.org/doc/rfc9110

    2022

  33. [42]

    Accessed: 2024-09-19

    (2024, Sep.) linkerd/linkerd2-proxy. Accessed: 2024-09-19. [Online]. Available: https://github.com/linkerd/linkerd2-proxy

    2024

  34. [43]

    Accessed: 2024-01-01

    (2024) Ubuntu Manpage: tc. Accessed: 2024-01-01. [Online]. Available: https://manpages.ubuntu.com/manpages/focal/man8/tc.8.html

    2024

  35. [44]

    Accessed: 2024-01-01

    (2024) envoy-dev. Accessed: 2024-01-01. [Online]. Available: https: //bit.ly/48MPeo1

    2024

  36. [45]

    Accessed: 2024-01-01

    (2024) Envoy proxy - home. Accessed: 2024-01-01. [Online]. Available: https://www.envoyproxy.io/

    2024

  37. [46]

    Accessed: 2024-01-01

    (2024, Jan.) envoyproxy/go-control-plane. Accessed: 2024-01-01. [Online]. Available: https://github.com/envoyproxy/go-control-plane

    2024

  38. [47]

    Accessed: 2024-01-01

    (2024) Envoy mobile. Accessed: 2024-01-01. [Online]. Available: https://github.com/envoyproxy/envoy-mobile

    2024

  39. [48]

    Accessed: 2024-01-01

    (2024) xDS configuration API overview. Accessed: 2024-01-01. [Online]. Available: https://www.envoyproxy.io/docs/envoy/latest/intro/ arch overview/operations/dynamic configuration

    2024

  40. [49]

    Accessed: 2024-01-01

    (2024) Apache CouchDB. Accessed: 2024-01-01. [Online]. Available: https://couchdb.apache.org/

    2024

  41. [50]

    Accessed: 2024-09-19

    (2024) Homepage | Ansible Collaborative. Accessed: 2024-09-19. [Online]. Available: https://www.ansible.com/

    2024

  42. [51]

    Accessed: 2024-09-23

    (2024) Hot restart — envoy 1.32.0-dev-cfb1b7 documentation. Accessed: 2024-09-23. [Online]. Available: https://www.envoyproxy.io/ docs/envoy/latest/intro/arch overview/operations/hot restart

    2024

  43. [52]

    Accessed: 2024-01-01

    (2024) FFmpeg. Accessed: 2024-01-01. [Online]. Available: https: //ffmpeg.org/

    2024

  44. [53]

    Accessed: 2024-01-01

    (2024) Open Policy Agent. Accessed: 2024-01-01. [Online]. Available: https://www.openpolicyagent.org/

    2024

  45. [54]

    Accessed: 2024- 01-01

    (2024) NASA Image and Video Library. Accessed: 2024- 01-01. [Online]. Available: https://images.nasa.gov/details/ JPL-20231227-M2020f-0001-Perseverance%20Rover%20Zooms% 20in%20on%20Ancient%20Mars%20River

    2024

  46. [55]

    Accessed: 2024-01-01

    (2024) Tunneling UDP over HTTP. Accessed: 2024-01-01. [Online]. Available: https://www.envoyproxy.io/docs/envoy/latest/intro/ arch overview/http/upgrades#tunneling-udp-over-http

    2024

  47. [56]

    Accessed: 2024- 01-01

    (2024) HTTP route components (proto). Accessed: 2024- 01-01. [Online]. Available: https://www.envoyproxy.io/ docs/envoy/latest/api-v3/config/route/v3/route components.proto# envoy-v3-api-msg-config-route-v3-retrypolicy

    2024

  48. [57]

    Accessed: 2024-01-01

    (2024) Ubuntu Manpage: Wget - The non-interactive net- work downloader. Accessed: 2024-01-01. [Online]. Available: https://manpages.ubuntu.com/manpages/trusty/man1/wget.1.html

    2024

  49. [58]

    Accessed: 2024-01-01

    (2024) time(1) - Linux manual page. Accessed: 2024-01-01. [Online]. Available: https://man7.org/linux/man-pages/man1/time.1.html

    2024

  50. [59]

    Accessed: 2024-01-01

    (2024) TCP Proxy (proto). Accessed: 2024-01-01. [On- line]. Available: https://www.envoyproxy.io/docs/envoy/latest/api-v3/ extensions/filters/network/tcp proxy/v3/tcp proxy.proto

    2024

  51. [60]

    Accessed: 2024-10-24

    (2024) Image Layer Details - envoyproxy/envoy:v1.32.0. Accessed: 2024-10-24. [Online]. Available: https://bit.ly/4fd07Cc

    2024

  52. [61]

    [Online]

    (2024) [Bug-wget] retry when unable to establish SSL connection? Accessed: 2024-11-15. [Online]. Available: https://lists.gnu.org/archive/ html/bug-wget/2019-08/msg00006.html

    2024

  53. [62]

    J. Shi. (2021, Feb.) What is a ”Face” in Named Data Networking? [Online]. Available: https://yoursunny.com/t/2021/NDN-face/

    2021

  54. [63]

    Accessed: 2024-09-23

    (2024) masque connect-ip failure · Issue #73 · google/quiche. Accessed: 2024-09-23. [Online]. Available: https://github.com/google/ quiche/issues/73

    2024

  55. [64]

    Accessed: 2024-09-24

    (2024) Protocol Selection. Accessed: 2024-09-24. [Online]. Avail- able: https://istio.io/latest/docs/ops/configuration/traffic-management/ protocol-selection/

    2024

  56. [65]

    Accessed: 2024-01-01

    (2024) ndncatchunks and ndputchunks. Accessed: 2024-01-01. [Online]. Available: https://github.com/named-data/ndn-tools/blob/master/tools/ chunks/README.md

    2024

  57. [66]

    An Evaluation of Service Mesh Frameworks for Edge Systems,

    Y . Elkhatib and J. P. Poyato, “An Evaluation of Service Mesh Frameworks for Edge Systems,” in Proceedings of the 6th International Workshop on Edge Systems, Analytics and Networking , ser. EdgeSys ’23. New York, NY , USA: Association for Computing Machinery, May 2023, pp. 19–...

    2023

  58. [67]

    HTTP3 / QUIC support · Issue #4723 · linkerd/linkerd2,

    “HTTP3 / QUIC support · Issue #4723 · linkerd/linkerd2,” 2024, accessed: 2024-09-24. [Online]. Available: https://github.com/linkerd/ linkerd2/issues/4723

    2024

  59. [68]

    PEPsal: a Performance Enhancing Proxy designed for TCP satellite connections,

    C. Caini, R. Firrincieli, and D. Lacamera, “PEPsal: a Performance Enhancing Proxy designed for TCP satellite connections,” in 2006 IEEE 63rd Vehicular Technology Conference , vol. 6, May 2006, pp. 2607–2611, iSSN: 1550-2252. [Online]. Available: https://ieeexplore. ieee.org/do...

    2006

  60. [69]

    Evaluation of performance enhancing proxies in internet over satellite,

    N. Ehsan, M. Liu, and R. J. Ragland, “Evaluation of performance enhancing proxies in internet over satellite,” International Journal of Communication Systems , vol. 16, no. 6, pp. 513–534, 2003. [Online]. Available: https://onlinelibrary.wiley.com/doi/abs/10.1002/dac.593

    2003 doi

  61. [70]

    On TCP performance enhancing proxies in a wireless environment,

    M. Ivanovich, P. W. Bickerdike, and J. C. Li, “On TCP performance enhancing proxies in a wireless environment,” IEEE Communications Magazine, vol. 46, no. 9, pp. 76–83, Sep. 2008, conference Name: IEEE Communications Magazine. [Online]. Available: https: //ieeexplore.ieee.org/...

    2008

  62. [71]

    QUIC-proxy based architecture for satellite communication to enhance a 5G scenario,

    A. Abdelsalam, M. Luglio, M. Quadrini, C. Roseti, and F. Zampognaro, “QUIC-proxy based architecture for satellite communication to enhance a 5G scenario,” in 2019 International Symposium on Networks, Computers and Communications (ISNCC) , Jun. 2019, pp. 1–6. [Online]. Availabl...

    2019

  63. [72]

    Transport over Het- erogeneous Networks Using the RINA Architecture,

    E. Trouva, E. Grasa, J. Day, I. Matta, L. T. Chitkushev, S. Bunch, M. P. de Leon, P. Phelan, and X. Hesselbach-Serra, “Transport over Het- erogeneous Networks Using the RINA Architecture,” in Wired/Wireless Internet Communications, X. Masip-Bruin, D. Verchere, V . Tsaoussidis,...

    2011

  64. [73]

    Networking named content,

    V . Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L. Braynard, “Networking named content,” in Proceedings of the 5th international conference on Emerging networking experiments and technologies, ser. CoNEXT ’09. New York, NY , USA: Association for...

    2009

  65. [74]

    Managing the Evolution to Future Internet Architectures and Seamless Interoperation,

    M. Jahanian, J. Chen, and K. K. Ramakrishnan, “Managing the Evolution to Future Internet Architectures and Seamless Interoperation,” in 2020 29th International Conference on Computer Communications and Networks (ICCCN) , Aug. 2020, pp. 1–11, iSSN: 2637-9430. [Online]. Availabl...

    2020

  66. [75]

    Internet indirection infrastructure,

    I. Stoica, D. Adkins, S. Zhuang, S. Shenker, and S. Surana, “Internet indirection infrastructure,” SIGCOMM Comput. Commun. Rev., vol. 32, no. 4, pp. 73–86, Aug. 2002. [Online]. Available: https://doi.org/10.1145/964725.633033

    2002

  67. [76]

    Accessed: 2024-01-

    (2024) Ubuntu Manpage: curl - transfer a URL. Accessed: 2024-01-

    2024

  68. [77]

    Accessed: 2024-01-01

    (2024) Project Gutenberg. Accessed: 2024-01-01. [Online]. Available: https://www.gutenberg.org/

    2024

  69. [78]

    Accessed: 2024-01-01

    (2024) patrikjuvonen/docker-nginx-http3:2.1.4. Accessed: 2024-01-01. [Online]. Available: https://bit.ly/4bm0AAS JOURNAL SUBMISSION 21 APPENDIX A. Research Reproducibility All prototype implementations and use cases we presented in this paper are available at address https://g...

    2024

  70. [79]

    Available: https://manpages.ubuntu.com/manpages/trusty/ man1/curl.1.html

    [Online]. Available: https://manpages.ubuntu.com/manpages/trusty/ man1/curl.1.html

  71. [80]

    Accessed: 2024-01-01

    (2024) OPAv0.60.0. Accessed: 2024-01-01. [Online]. Available: https: //bit.ly/486HrjW

    2024

  72. [2014]

    Available: https://doi.org/10.1145/2656877.2656887

    [Online]. Available: https://doi.org/10.1145/2656877.2656887

Pith tools

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