Subject: Public API requests for application-driven multipath control

[aalrashad]

Hi n0 team,
We're auditing noq v1.0.0-rc.0 as substrate for an open broadcast contribution protocol over Multipath QUIC. noq is structurally the closest Rust MP-QUIC we've found — thank you for the work.
Four public API additions would let us use noq directly:

Per-path local socket binding — bind specific paths to specific NICs/sockets, e.g. Endpoint::add_path_with_socket(path_id, socket).
App-controlled per-send path scheduling — Connection::send_datagram_on_path(path_id, data) plus optional scheduler callback. Internal "lowest non-congested path" works for many cases; ours needs application policy per packet.
Configurable sub-200ms path abandonment — current 3 * demote_timer autonomous abandonment is ~3s. Add TransportConfig::min_path_abandonment_timeout(duration) and a latency bound for user-initiated Path::close().
Receiver-side multipath bonding — server accepting one connection over multiple local sockets, with documented multi-address advertisement and example.

Happy to file these as separate issues with concrete signatures and contribute PRs where appropriate.
Thanks,
Akram

[matheus23]

Per-path local socket binding — bind specific paths to specific NICs/sockets, e.g. Endpoint::add_path_with_socket(path_id, socket).

We do plan on having that. Together with each local socket having its own separate TransportConfig.

That said, this is a noq 2.0 rather than a noq 1.0 feature. It's quite a refactor.

The good news is that iroh (which uses noq) already does that: You can "hide" multiple sockets behind a single AsyncUdpSocket. It's not terribly elegant, but it works just fine.

App-controlled per-send path scheduling — Connection::send_datagram_on_path(path_id, data) plus optional scheduler callback. Internal "lowest non-congested path" works for many cases; ours needs application policy per packet.

This is definitely something we'll want to do. We call that "stream path affinity". The idea would be to be able to constrain a stream to only send on a particular path ID.
This will likely be a feature in one of the 1.x noq releases. If you want us to work on this sooner, please get in touch! https://n0.computer

Configurable sub-200ms path abandonment — current 3 * demote_timer autonomous abandonment is ~3s. Add TransportConfig::min_path_abandonment_timeout(duration) and a latency bound for user-initiated Path::close().

I don't think this is a wise thing to do. It's totally possible that there's a network blip for more than 200ms. You wouldn't want all of your paths to be abandoned by that point.
Rather the plan should be to improve path scheduling, such that we move away from paths that have experienced packet loss as soon as possible.

Receiver-side multipath bonding — server accepting one connection over multiple local sockets, with documented multi-address advertisement and example.

Again, I recommend taking a look at iroh. We do this in iroh - including duplicating Initial packets so that the fastest connection establishment (relay, ipv4, ipv6, any custom transport such as bluetooth) wins. But it's a little bit involved at the moment: We use a custom "special address" as a sort of "anycast address for a particular server endpoint" that is local to the client. The sockets know how to deal with that anycast address and translate poll_send calls to it to individual poll_send calls to each address.
Again, this works, but can be somewhat quirky. We're continuously improving the QUIC side of iroh to make these things less hacky. Our plan is to eventually write a QUIC extension that allows you to dial multiple server addresses at once, racing all attempts and only establishing a single connection. However, that's a future thing! Again - happy to talk about things like this business wise: https://n0.computer