getMoqtProtocols() preserves caller order: an ascending --versions list advertises moq-00 first and pins sessions to draft-14

[gmarzot]

getMoqtProtocols() preserves the caller's numeric order, and getAlpnFromVersion(14, useStandard=true) returns the legacy ALPN because the draftNum < 15 branch precedes the useStandard branch. A version list written in ascending order therefore advertises moq-00 first, and every session silently pins to draft-14.

Reproduction

moqrelayserver on localhost, identical client build in every row, client offering moqt-18, moqt-16, moqt-15, moq-00:

relay --versions	resulting server ALPN list	negotiated
(unset — default)	moqt-18, moqt-16, moqt-15, moq-00	draft-18
18,16,14	moqt-18, moqt-16, moq-00	draft-18
14,16,18	moq-00, moqt-16, moqt-18	draft-14

Selection follows server preference, so the relay's list order decides the outcome. The same effect is observable against fb.mvfst.net:9448, which negotiates draft-14 with a client offering all four ALPNs but draft-18 when the client pins moqt-18.

Why this is easy to hit

Ascending is the natural way to write the flag, and it matches how draft support is conventionally listed elsewhere — the interop runner registry, for instance, lists draft_versions: ["draft-14","draft-16","draft-18"]. Nothing in the flag's help text ("Comma-separated MoQ draft versions (e.g. '14,16'). Empty = all supported.") suggests order is significant, and there is no diagnostic when the legacy ALPN ends up ahead of the standard ones.

Not a request to change the published defaults

getDefaultMoqtProtocols(true, ...) already emits moqt-18, moqt-16, moqt-15, moq-00, which is correct, and the empty-versions path routes to it. The unset-flag behaviour is fine as shipped. This is only about the explicit-list path, where the caller's ordering silently becomes load-bearing.

Options

Listed for your judgement rather than as a preference — the tradeoffs around fielded behaviour here are yours:

1. Sort the result by descending draft regardless of input order.
2. Keep input order, but log a warning when a legacy ALPN precedes a standard one.
3. Keep the behaviour and document in the flag help that order expresses preference, most-preferred first.

There is currently no test coverage for MoQVersions — no getMoqtProtocols, getAlpnFromVersion, getVersionFromAlpn, or getDefaultMoqtProtocols test anywhere in the tree. Happy to add a characterisation test for whichever behaviour you settle on.

[gmarzot]

Implemented the three changes locally and ran the result against fb.mvfst.net:9448. The negotiated-version reporting (item 3) immediately surfaced something worth flagging before this lands.

Measured behaviour against fb.mvfst.net:9448

Identical on raw QUIC and WebTransport:

ALPNs offered by client	negotiated
moqt-16, moq-00 (the current hardcoded list, emulated)	draft-14
moqt-18, moqt-16, moqt-15, moq-00 (derived, this change)	draft-14
moqt-18 (pinned via the new --versions)	draft-18
moqt-16 (pinned)	draft-16

Client: Negotiated ALPN: moq-00
Negotiated Version=0xff00000e (draft-14)

So the interop client has not been reaching draft-16 either — it has been speaking draft-14 throughout. Draft-18 itself is fine: pinned runs pass setup-only on both transports.

Root cause: the version list order is load-bearing

Reproduced locally with moqrelayserver, same client build in every row:

relay --versions	resulting server ALPN list	negotiated
(unset — default)	moqt-18, moqt-16, moqt-15, moq-00	draft-18
18,16,14	moqt-18, moqt-16, moq-00	draft-18
14,16,18	moq-00, moqt-16, moqt-18	draft-14

getMoqtProtocols() preserves the caller's numeric order, and getAlpnFromVersion(14, useStandard=true) returns moq-00 because the draftNum < 15 branch precedes the useStandard branch. So a list written in ascending order puts the legacy ALPN first, and every session silently pins to draft-14.

Ascending is the intuitive way to write the flag, and it is also how draft support is listed in the interop registry (draft_versions: ["draft-14","draft-16","draft-18"]), which is likely how this went unnoticed.

Notes

• This is separable from the client-side changes proposed above; those stand on their own and are what made it visible. Happy to open a distinct issue for the ordering behaviour if that is preferred — getMoqtProtocols() arguably should order by descending draft regardless of input, since the current contract makes an easy-to-write configuration silently select the oldest draft.
• Relevant to any concern about clients and servers in the field switching drafts abruptly: they will not, for as long as moq-00 is offered ahead of the standard ALPNs. Preference order, not capability, is what is holding negotiation at draft-14 today.

[gmarzot]

Retargeted this issue to the ordering behaviour only. The original scope — deriving the interop client's ALPNs, adding --versions/MOQT_VERSIONS, and reporting the negotiated draft — landed as 2787248 via #222, with the divergent-version handling added in review. The measurement comment above predates the retarget and is what surfaced this.