Noq: n0's new QUIC implementation in Rust

Today we're delighted to announce noq (”number 0 QUIC”), our own general purpose QUIC implementation with multipath and NAT traversal support. It is the transport layer that has been powering iroh since v0.96, though is in no way limited to iroh's usecase.

From soft fork to hard fork

If you've been following iroh's development, you may have read why we forked Quinn back in 2024. The short version: iroh was doing a lot of heavy lifting around QUIC: switching between relay and direct paths, managing NAT traversal, juggling congestion state. But QUIC itself had no visibility into any of it. That mismatch created problems that we couldn't fix from the outside.

Our fork started small. We wanted to track upstream Quinn closely, contribute back where we could, and keep our diff minimal. That was the right call at the time. But as we pushed further into QUIC multipath, NAT traversal, and our own relay-as-a-path architecture, the development velocity of the two projects drifted into iteration cycles that didn't match. All our constant changed would lead to an unreasonable review burden for the Quinn maintainers. The n0 team wanted to try deeper, structural changes to our QUIC implementation, and it would have been unfair to foist the consequences of those changes onto all Quinn users. We think a hard fork with a continued commitment to collaboration makes more sense all around.

What's in noq

The headline feature is a full implementation of the QUIC Multipath spec. This is where the real architectural shift happened, both inside Quinn/noq and for iroh's use. Before multipath, iroh managed multiple paths (relay, direct IPv4, direct IPv6) as a kind of sleight of hand below the QUIC layer. Quinn thought it was talking to the other endpoint via just one IP address while we shuffled packets across whichever path was working best.

With multipath, those paths are first-class QUIC concepts. The relay path is a QUIC path. The direct UDP path is a QUIC path. QUIC knows about all of them, maintains per-path congestion state, and can reason about which one to use. This means the latency improvements we had to hack in via congestion controller resets are now handled correctly and systematically.

We've implemented our own interpretation of the QUIC NAT traversal draft. To our knowledge we're the first to do this in a production-grade, robust way. Expressing NAT traversal hole-punching directly as a QUIC-level operation, rather than something happening beneath it, is cleaner and more reliable, because it makes the QUIC congestion controller aware of it and allows better loss detection.

iroh has been using our implementation of QUIC Address Discovery (QAD) since iroh version 0.32. QAD uses QUIC connections to learn about public IP addresses of clients, which was previously done using STUN. QUIC enables encrypting these packets without sacrificing round-trips compared to STUN, preventing protocol ossification and enhancing user privacy.

In noq the qlog support has been greatly extended to support many more events from the main qlog logging schema. Additionally qlog's extensability was used to add events for QUIC multipath. While most of noq's API changes are around the multipath support we also added a WeakConnectionHandle. This is a type that does not keep a connection alive itself, but can be upgraded to a full Connection if it was not dropped yet.

Already in production

noq shipped as part of iroh v0.96 and has been running in production since then. If you're using a recent version of iroh, you're already using noq. Apart from shipping and testing noq's multipath implementation against itself, we've also been running interoperability tests against picoquic, one of the reference implementations used in QUIC working group interop events.

What's next

We see noq as a long-term foundation. There is more work that we want to do such as further NAT traversal improvements. The multipath work also opens up performance optimizations that weren't possible before. We'll continue to engage with the QUIC working group and collaborate with the Quinn team on areas where our interests align.