blog: draft "Paradox: More Hops, Lower Latency"

[kixelated]

Draft blog post at src/pages/blog/more-hops-lower-latency.mdx, written in the same rant register as Never* use Datagrams and Forward? Error? Correction?.

The argument

In section order:

• The math: loss recovery costs ~1 RTT of the longest hop, so a 100ms path needs a 150ms jitter buffer, while two 50ms hops need 75ms. Subdivide again for 37.5ms.
• Why it works: IP has no way to signal or repair loss mid-path, so only the endpoints know. A QUIC/TCP proxy changes the topology of knowledge, for ~1ms per hop and a monthly bill.
• FEC problem 1: loss is bursty, so parity must be time-offset — which reinvents the jitter buffer it was supposed to delete.
• FEC problem 2: bursts are congestion, and answering congestion with 50% more bytes deepens the queue that just overflowed. Plus you pay for that egress at scale.
• Pop quiz: CDN edges exist to shorten the lossy first/last hop; L7 dedup of HTTP requests and MoQ subscriptions is the bonus round.
• P2P: fewest hops means no place to repair loss, which is why P2P reaches for FEC and eats both taxes.
• In defense of parity: genuinely random loss (already handled by WiFi/5G/DOCSIS), hops you can't subdivide (space, satellite), and small tolerant payloads (audio). Video is the opposite of all three.
• Closes with the traceroute heuristic, the moq.pro plug, and links back to the older rants.

Notes for review

• Cover image is a placeholder — it reuses /blog/first-cdn/global.png so the blog index doesn't render a broken thumbnail. Needs a real image (and a public/blog/more-hops-lower-latency/ directory) before shipping.
• date is set to 2026-08-19. Worth noting that per CLAUDE.md, any .mdx under src/pages/blog/ ships and gets announced on the next just deploy live, drafts included — so this shouldn't merge until it's ready to mail.
• No inline figures beyond the one placeholder; a couple of spots (the hop-subdivision math, the bufferbloat section) would land better with diagrams.
• Verified with bunx astro build: the post renders and appears in both /blog/ and rss.xml. biome check is clean apart from a pre-existing config-migration info.

Commits

1. The draft itself.
2. Moves the FEC concession from the middle of the post to second-to-last, matching the "In Defense of X" beat the earlier two rants use. Retitled "In Defense of Parity" to avoid colliding with the old post's "In Defense of FEC".

🤖 Generated with Claude Code

https://claude.ai/code/session_018Y8uAFWYzVPZ2e5UGw8DPx

[kixelated]

OG text:

can you help me make a draft for a new blog post in the usual style? Very similar to never use datagrams

Paradox: More Hops, Lower Latency

I want to shit on FEC some more. Some robotics teleop companies are peddling it. Also to (partially) explain why P2P is lower quality (or higher latency).

The argument is that you want proxy nodes to split a lossy RTT into smaller and smaller segments. If there's packet loss over a 100ms RTT link, it takes at least 100ms to detect the loss and ~50ms for the retransmission to arrive, so you need a jitter buffer size of 150ms. But if you split the link into two 50ms hops, now it's 75ms. Further subdivisions.

The reason is that IP/UDP has no retransmission mechanism or way to signal loss. By putting a TCP/QUIC proxy in the middle, you can now retransmit. It might add 1ms of latency because we have to hand each packet off from the router (L2) into the app (L3/L7). It's also going to be more expensive too, hardware routers versus software proxies.

A counterargument is FEC. Instead of retransmitting lost packets on demand, you retransmit them opportunistically (parity bits). If a packet is randomly dropped, you can probably reconstruct it, if not fall back to a retransmit.

problems:

1. packet loss over the Internet generally isn't random. It occurs in bursts, so your FEC packets have to be time offset (ex. parity sent 50ms later).
2. Bursty packet loss is often due to bufferbloat (IP queues full), so sending more packets can aggrevate the situation.

bufferbloat is the cause of latency you should be worried about. Routers queuing packets for an indeterminate amount of time, dropping them when the queue is full (and latency is maximized). You need to send fewer bytes to drain these queues to the baseline latency, not transmit 50% more as parity. And keep in mind that you end up paying real money for this redundant egress at scale.

FEC is a good idea when packet loss is truely random and not due to capacity (ex. signal interference). The lower level protocols (ex. wifi, 5G) do this for you based on the signal characteristics of the interface.

FEC is also a good idea when you can't put proxies in the middle, aka in space. If you can't daisy chain but latency is important, then slap on a bunch of parity packets.

And finally, FEC can work when your payload is small and tolerates loss. aka audio packets. But it's a terrible fit for video with our current codecs that take delta encoding to the extreme.

A quiz: Why do CDN have edge nodes in every metro?

Duh it's to make the lossy first/last hop as short as possible to minimize latency.

Each L7 hop can deduplicate identical HTTP requests or MoQ subscriptions. This is how my favorite protocols scale; only one copy of the content makes it to each data center that needs it.

But even for 1:1 traffic, you still want edge nodes. The CDN can either daisy chain like mentioned above, or it can overprovision the backbone so the relatively long hops are congestion free.

I'm the world's biggest FEC hater. I'm in good company because QUIC doesn't support FEC, nor does TCP. The cloud companies hyper optimizing these protocols do it by moving the cloud closer to the users.

It's a red flag if a live protocol advertises FEC. Either they don't understand networking the same way I do, or they're running the wrong infrastructure. traceroute the connect IP address and if it's not <20ms, alarm bells.

btw pay for MoQ.pro. Unless you're a big boye, it's not economically viable to run your own edges world wide. Pool your money with other customers so you can share a fraction of a global presence.