{"id":"35d9e17f-b2b1-4861-830f-11cfa11c76ca","arxiv_id":"2411.13668","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A proxy overlay using HTTP tunneling can provide backward compatibility, reliability, policy routing, and support for future network architectures, per the paper's prototype evaluations.","lead":"Hermes is a proposed networking architecture that places reconfigurable proxy software on end-user devices and network paths, using HTTP tunnels to carry UDP, TCP, and IP traffic. The authors prototype it with Envoy and show it can recover UDP video streaming, retry across broken links, reroute IP traffic, and carry NDN traffic, with mixed performance results.","discovery_kind":"extension","skeptic_critique":null,"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":29881,"tokens_out":7992,"duration_ms":77548,"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":[{"comment":"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.","section":"Abstract / Section III"},{"comment":"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.","section":"Section III-B"},{"comment":"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.","section":"Section III-B.3"}],"minor_comments":[{"comment":"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.","section":"Section III-D"},{"comment":"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.","section":"Section III-C.3"},{"comment":"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.","section":"Section II-D.6"},{"comment":"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.","section":"Section III (all use cases)"},{"comment":"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.","section":"Table III"},{"comment":"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]).","section":"Section IV"},{"comment":"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.","section":"Throughout"}],"recommendation":"major_revision","confidential_remarks":"The paper is a solid systems contribution with reproducible prototypes and an honest treatment of several limitations, but the abstract overstates what the body demonstrates. The main revisions are: (1) align the abstract with the measurements actually presented; (2) address the fine-tuning circularity in the Intermittent use case; (3) clarify the secure-mode reliability result. No concerns about citation practices or scope."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: Hermes is a genuine systems paper, not vaporware. It combines Envoy, HTTP CONNECT/MASQUE, OPA, and xDS into a reconfigurable end-user-to-edge proxy overlay with a control plane, and it demonstrates the architecture on four actual prototypes: UDP video compatibility, intermittent TCP, IP policy routing, and NDN namespace mapping. The architecture definition is clear enough that someone could reproduce the setup, and the paper is honest in important places: Section III-B explicitly concedes that the retry parameters \"might look like to be fine-tuned for this particular example,\" and the NDN section reports a 12% slowdown instead of hiding it.\n\nWhat is genuinely new is the combination: a general-purpose overlay that pushes reconfigurable proxies to end-user devices, uses HTTP headers as a semantic routing layer, and wraps IP/UDP traffic through MASQUE-style tunnels under a control plane. The building blocks are existing, so this is combinatorial novelty, but the combination is useful. The IP policy-routing use case (two users sharing 10.0.0.1 but mapped to different physical destinations, with dynamic ingress migration) and the NDN namespace-to-address-space mapping are the most convincing demonstrations. The related-work discussion engages service meshes, PEPs, Trotsky, and I-3 fairly, though the \"first general-purpose proxy overlay\" claim is stronger than the table actually supports.\n\nThe main soft spots are real but not fatal. First, the abstract's overhead claim (under 2 ms per proxy pair, up to 1,000 concurrent requests) does not appear in the body; there is no overhead benchmark reported. Second, the intermittent success ratio is effectively set by hand-tuned retry parameters in Table XIII, matched to the specific three-link slot pattern. Without a method to derive those parameters automatically, the general reliability claim does not follow from the demonstration. Third, the IP use case includes a manually set max-stream-duration tweak to prevent Envoy crashes, and no statistical significance tests are reported anywhere. The NDN standard deviations are tiny, but no test is given.\n\nNone of these flaws sink the architecture. The right outcome is major revision: add the missing overhead experiment, propose automatic retry configuration or at least a sensitivity analysis, and soften the abstract to match the body. This paper deserves a serious referee. The audience is networking systems researchers interested in overlays, HTTP as a narrow waist, NDN deployment, and service-mesh generalization. I would bring it to a reading group for the architecture discussion, and I would cite it as the most complete public example of this proxy-overlay approach, while being careful not to lean on the unverified overhead numbers.","headline":"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.","tokens_in":30413,"tokens_out":4340,"would_cite":true,"duration_ms":70473,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["overlay networking","HTTP tunneling","proxy architecture","policy-based routing","Named Data Networking","reliability in unstable networks","backward compatibility","control plane"],"falsifier":"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.","tokens_in":29755,"feed_emoji":"🌐","tokens_out":8184,"duration_ms":81109,"temperature":0.7,"pith_summary":"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.","feed_headline":"Proxy overlay handles app networking under 2 ms overhead","feed_subtitle":"Hermes routes, retries, and translates traffic for apps across four emulated use cases.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the observation that HTTP can serve as the internet's narrow waist, motivating the choice of HTTP as the overlay's unifying substrate.","marker":"[19]"},{"why":"Provides the CONNECT-UDP method used to tunnel UDP traffic over HTTP in the video and IP use cases.","marker":"[20]"},{"why":"Provides the CONNECT-IP method that the architecture adopts for carrying IP packets over HTTP.","marker":"[21]"},{"why":"Defines the MASQUE framework that extends HTTP to proxy UDP, IP, and Ethernet, central to Hermes' compatibility story.","marker":"[23]"},{"why":"Supplies the architecture definition Hermes uses and the extensibility agenda that Hermes extends with a proxy overlay.","marker":"[2]"},{"why":"Exemplifies a proxy-based overlay for privacy, used as a precedent for general-purpose proxy overlays.","marker":"[7]"},{"why":"Exemplifies a performance-enhancing overlay using DNS redirection, used as the comparison baseline for overlay routing.","marker":"[8]"},{"why":"Defines Named Data Networking, the future architecture Hermes carries as a communication pipeline in the fourth use case.","marker":"[12]"},{"why":"Provides the prior result that direct TCP fails under the same intermittent-link pattern, which the Hermes reliability use case is designed to beat.","marker":"[38]"},{"why":"Defines performance-enhancing proxies, the category Hermes extends from a special-purpose tool to a general architecture.","marker":"[6]"}],"fun_headline_variants":["One proxy overlay solves four network challenges under 2ms","Hermes proxy mesh handles routing, compatibility, security, and adaptability","Proxy overlay cuts app networking overhead to under 2ms","Hermes unifies traffic, compatibility, privacy, and adaptation in one overlay","Proxy overlay improves video, downloads, and NDN with minimal overhead"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["One proxy overlay solves four network challenges under 2ms","Hermes proxy mesh handles routing, compatibility, security, and adaptability","Proxy overlay cuts app networking overhead to under 2ms","Hermes unifies traffic, compatibility, privacy, and adaptation in one overlay","Proxy overlay improves video, downloads, and NDN with minimal overhead"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000528,"raw_usage":{"total_tokens":2583,"prompt_tokens":1020,"completion_tokens":1563,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":636,"completion_tokens_details":{"reasoning_tokens":1474}},"tokens_in":636,"tokens_out":1563,"duration_ms":16044,"temperature":1.0,"reasoning_tokens":1474,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T16:00:24.299741+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Proxying UDP in HTTP,","cited_arxiv_id":null,"evidence_quote":"Provides the CONNECT-UDP method used to tunnel UDP traffic over HTTP in the video and IP use cases."},{"cited_title":"Proxying IP in HTTP,","cited_arxiv_id":null,"evidence_quote":"Provides the CONNECT-IP method that the architecture adopts for carrying IP packets over HTTP."},{"cited_title":"The MASQUE Proxy,","cited_arxiv_id":null,"evidence_quote":"Defines the MASQUE framework that extends HTTP to proxy UDP, IP, and Ethernet, central to Hermes' compatibility story."},{"cited_title":"Tor: the second- generation onion router,","cited_arxiv_id":null,"evidence_quote":"Exemplifies a proxy-based overlay for privacy, used as a precedent for general-purpose proxy overlays."},{"cited_title":"The Akamai network: a platform for high-performance internet applications,","cited_arxiv_id":null,"evidence_quote":"Exemplifies a performance-enhancing overlay using DNS redirection, used as the comparison baseline for overlay routing."},{"cited_title":"Named data networking,","cited_arxiv_id":null,"evidence_quote":"Defines Named Data Networking, the future architecture Hermes carries as a communication pipeline in the fourth use case."},{"cited_title":"Mitigating Intermittent Links With Name-Based Networking,","cited_arxiv_id":null,"evidence_quote":"Provides the prior result that direct TCP fails under the same intermittent-link pattern, which the Hermes reliability use case is designed to beat."},{"cited_title":"Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations,","cited_arxiv_id":null,"evidence_quote":"Defines performance-enhancing proxies, the category Hermes extends from a special-purpose tool to a general architecture."}],"review_version":1}