Research: fastest data path between clients and targets (P6)

kayg commented

2026-10-07 05:39:43 +00:00

Owner

Owner question P6 (2026-10-07): what is the fastest data path for a session between the owner's devices and a target, when the server is in Germany (monitor01, Essen) but the owner and the target (the Mac VM) are both in India?

Measured: build box (Falkenstein) ↔ monitor01 9.7 ms; build box ↔ Mac VM 152 ms minimum (direct NetBird P2P; avg 436 ms with spikes to 1.4 s over 5 pings). NetBird itself adds little; the distance does. Today the data path for a session goes client → server → infraternal agent → target (DECISIONS 63: browser↔server is WebSocket only). With the server in Europe, an India↔India session crosses intercontinental links twice.

This issue holds the research: direct client↔agent data paths with the server only authorizing, relays placed near users, and what each means for security (DECISIONS 9, 63, 64) and for Safari and iOS.

Owner question P6 (2026-10-07): what is the fastest data path for a session between the owner's devices and a target, when the server is in Germany (monitor01, Essen) but the owner and the target (the Mac VM) are both in India? Measured: build box (Falkenstein) ↔ monitor01 9.7 ms; build box ↔ Mac VM 152 ms minimum (direct NetBird P2P; avg 436 ms with spikes to 1.4 s over 5 pings). NetBird itself adds little; the distance does. Today the data path for a session goes client → server → infraternal agent → target (DECISIONS 63: browser↔server is WebSocket only). With the server in Europe, an India↔India session crosses intercontinental links twice. This issue holds the research: direct client↔agent data paths with the server only authorizing, relays placed near users, and what each means for security (DECISIONS 9, 63, 64) and for Safari and iOS.

kayg commented

2026-10-07 05:40:28 +00:00

Author

Owner

Started research on branch research-path, based at 411b1195c0. Issue has no prior comments; no separate parent issue found in search.

Started research on branch research-path, based at 411b1195c0e1dc7ef1ddb00c59bb153a5fdfc89e. Issue has no prior comments; no separate parent issue found in search.

kayg commented

2026-10-07 05:51:16 +00:00

Author

Owner

Section 1 drafted in research/data-path/REPORT.md (working tree at base 411b1195c0). Five-minute samples: build box↔monitor01 300/300, 9.912 ms mean, 0.698 ms mdev; build box→Mac TCP/22 300/300, p50 152.665/p99 160.425/max 175.116 ms; Mac↔monitor01 299/300, 198.118 ms mean, 1.432 ms stddev. NetBird status was P2P on each pair. Mac fallback relay o1.kayg.org resolves to 144.24.150.105, estimated Hyderabad; Mac↔relay 23.394 ms and monitor01↔relay 171.139 ms (5 samples each), so symmetric relay RTT estimate is 194.5 ms, not an observed relayed session.

Section 1 drafted in research/data-path/REPORT.md (working tree at base 411b1195c0e1dc7ef1ddb00c59bb153a5fdfc89e). Five-minute samples: build box↔monitor01 300/300, 9.912 ms mean, 0.698 ms mdev; build box→Mac TCP/22 300/300, p50 152.665/p99 160.425/max 175.116 ms; Mac↔monitor01 299/300, 198.118 ms mean, 1.432 ms stddev. NetBird status was P2P on each pair. Mac fallback relay o1.kayg.org resolves to 144.24.150.105, estimated Hyderabad; Mac↔relay 23.394 ms and monitor01↔relay 171.139 ms (5 samples each), so symmetric relay RTT estimate is 194.5 ms, not an observed relayed session.

kayg commented

2026-10-07 05:52:59 +00:00

Author

Owner

Section 2 drafted in research/data-path/REPORT.md (working tree still based at 411b1195c0). The model is RTT(client,server)+RTT(server,agent) for the current path versus one direct RTT or RTT(client,relay)+RTT(relay,agent). Under the measured o1 triangle, relaying monitor01↔Mac estimates 194.5 ms versus 198.1 ms direct; an India client↔o1 leg is still unmeasured. Safari WebTransport is available starting 26.4/iOS 26.4, below iOS 17 is unavailable; the report also records certificate-hash, NAT, trust/audit and Safari interop constraints. No transport chosen.

Section 2 drafted in research/data-path/REPORT.md (working tree still based at 411b1195c0e1dc7ef1ddb00c59bb153a5fdfc89e). The model is RTT(client,server)+RTT(server,agent) for the current path versus one direct RTT or RTT(client,relay)+RTT(relay,agent). Under the measured o1 triangle, relaying monitor01↔Mac estimates 194.5 ms versus 198.1 ms direct; an India client↔o1 leg is still unmeasured. Safari WebTransport is available starting 26.4/iOS 26.4, below iOS 17 is unavailable; the report also records certificate-hash, NAT, trust/audit and Safari interop constraints. No transport chosen.

kayg commented

2026-10-07 05:53:22 +00:00

Author

Owner

Section 3 drafted in research/data-path/REPORT.md (working tree based at 411b1195c0). Sourced product patterns: Tailscale and Parsec use direct paths with relay fallbacks; Teleport, Cloudflare browser rendering, and Guacamole keep a proxy in the data path; WARP/Mesh and Moonlight VPN make device routes available to enrolled clients. No vendor latency figures are compared because the network tests are not same-workload benchmarks.

Section 3 drafted in research/data-path/REPORT.md (working tree based at 411b1195c0e1dc7ef1ddb00c59bb153a5fdfc89e). Sourced product patterns: Tailscale and Parsec use direct paths with relay fallbacks; Teleport, Cloudflare browser rendering, and Guacamole keep a proxy in the data path; WARP/Mesh and Moonlight VPN make device routes available to enrolled clients. No vendor latency figures are compared because the network tests are not same-workload benchmarks.

kayg commented

2026-10-07 05:56:23 +00:00

Author

Owner

Section 4 drafted in research/data-path/REPORT.md (working tree based at 411b1195c0). Chromium 153 on infraternal-dev ran 300 sequential echoes per path to a temporary listener on monitor01: WebSocket p50/p99 10.4/12.2 ms, DataChannel 11.0/12.9 ms (+0.6/+0.7 ms). ICE selected UDP 10.69.69.125↔10.69.69.50; setup to DataChannel open took 5.389 s in one run. Both echo endpoints were on monitor01, so this does not include the remote Mac leg or represent production WSS/auth.

Section 4 drafted in research/data-path/REPORT.md (working tree based at 411b1195c0e1dc7ef1ddb00c59bb153a5fdfc89e). Chromium 153 on infraternal-dev ran 300 sequential echoes per path to a temporary listener on monitor01: WebSocket p50/p99 10.4/12.2 ms, DataChannel 11.0/12.9 ms (+0.6/+0.7 ms). ICE selected UDP 10.69.69.125↔10.69.69.50; setup to DataChannel open took 5.389 s in one run. Both echo endpoints were on monitor01, so this does not include the remote Mac leg or represent production WSS/auth.

kayg commented

2026-10-07 05:57:29 +00:00

Author

Owner

Section 5 review checks are in research/data-path/REPORT.md (working tree based at 411b1195c0). I checked probe direction/counts, separated live P2P from fallback relays, labeled estimates, linked sources, and left D8-D11/D63-D64/D104-D107/D117 unchanged. No concurrency, mobile Safari, throughput, or real input-to-photon benchmark is claimed.

Section 5 review checks are in research/data-path/REPORT.md (working tree based at 411b1195c0e1dc7ef1ddb00c59bb153a5fdfc89e). I checked probe direction/counts, separated live P2P from fallback relays, labeled estimates, linked sources, and left D8-D11/D63-D64/D104-D107/D117 unchanged. No concurrency, mobile Safari, throughput, or real input-to-photon benchmark is claimed.

kayg commented

2026-10-07 05:57:30 +00:00

Author

Owner

Section 6 shortlist and owner questions are in research/data-path/REPORT.md (working tree based at 411b1195c0). Investigation order starts with the owner's actual mesh path, then WebRTC/TURN and a measured India relay, with server placement and direct WebSocket/WebTransport conditional on geography, browser floor, NAT, and PKI. No decision made.

Section 6 shortlist and owner questions are in research/data-path/REPORT.md (working tree based at 411b1195c0e1dc7ef1ddb00c59bb153a5fdfc89e). Investigation order starts with the owner's actual mesh path, then WebRTC/TURN and a measured India relay, with server placement and direct WebSocket/WebTransport conditional on geography, browser floor, NAT, and PKI. No decision made.

kayg commented

2026-10-07 06:00:21 +00:00

Author

Owner

Finished report: research/data-path/REPORT.md. Head: 42217c49fe. Five-minute samples: buildbox↔monitor01 9.912 ms mean, 0/300 loss; buildbox→Mac TCP connect 153.220 ms mean, p99 160.425 ms, 0/300 failures; Mac↔monitor01 198.118 ms mean, 1/300 loss. Active peer links were P2P. Prototype WebRTC was +0.6 ms p50 versus WebSocket on the same 10 ms path. Required gate output (verbatim): zsh:1: no such file or directory: scripts/verify (exit 127).

Finished report: `research/data-path/REPORT.md`. Head: 42217c49fec21eb97560ef0f88d5c715a2d88535. Five-minute samples: buildbox↔monitor01 9.912 ms mean, 0/300 loss; buildbox→Mac TCP connect 153.220 ms mean, p99 160.425 ms, 0/300 failures; Mac↔monitor01 198.118 ms mean, 1/300 loss. Active peer links were P2P. Prototype WebRTC was +0.6 ms p50 versus WebSocket on the same 10 ms path. Required gate output (verbatim): `zsh:1: no such file or directory: scripts/verify` (exit 127).

kayg referenced this issue from a commit

2026-10-10 09:20:38 +00:00

research(data-path): keep the fastest-path report on main (#47)

kayg referenced this issue from a commit

2026-10-10 09:20:38 +00:00

decisions: 122 high latency is the design case, 123 any browser works, 124 enterprise scale target

kayg referenced this issue from a commit

2026-10-10 09:20:38 +00:00

decisions: 126 machine tab and share card, 127 session manager, 128 latency and session data path

kayg referenced this issue from a commit

2026-10-10 09:20:58 +00:00

docs: compare client-target data paths for #47