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.

So we went all the way. We explained our thinking in the Quinn multipath issue thread. This isn't a rejection of Quinn, which remains a great implementation. It's an acknowledgment that the problems we're solving are specific enough that a separate codebase, with collaboration where our interests overlap, is the honest path forward.

What's in noq

QUIC Multipath

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. Kind of like iroh's own small NAT around Quinn.

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.

The multipath implementation is generic though, it does not only serve iroh. It aims at being a full implementation of the [QUIC Multipath spec], for any purpose. The implementation is still young however, so if you need more APIs from it, let us know.

QUIC NAT Traversal

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. NAT traversal is notoriously finicky, getting it right across the full range of NAT behaviors in the wild is a hard problem, and we've been battle-testing our approach across the hundreds of thousands of devices already running iroh. Though this is in no way a settled spec yet, we will keep iterating.

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.

QUIC Address Discovery

iroh has been using out 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 enhanced user privacy.

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.

If you're working on QUIC implementations, p2p transport, or applications that need to run across diverse network conditions, we'd love to talk. Come find us on Discord or open an issue on GitHub.

If you're eager to try out a rust QUIC multipath implementation, take a look at the documentation for a multipath noq Connection.