RE: Transport parameters for version negotiation and v2

[Nick Banks <[e-mail]>]

MsQuic has released a version with VN+V2 support, but it's marked as "preview" so it can change, as necessary. We weren't planning to make it an official feature until the RFCs.

Thanks,
- Nick
Sent from Outlook<http://aka.ms/weboutlook>
From: QUIC <[e-mail]> On Behalf Of Martin Duke
Sent: Thursday, November 17, 2022 8:45 PM
To: Christian Huitema <[e-mail]>
Cc: Martin Thomson <[e-mail]>; [e-mail]
Subject: Re: Transport parameters for version negotiation and v2

In Google's code, the v2 code is exists but is not in production because we haven't done compatible VN yet. So changing the transport parameter at this point would have no impact on Chrome or Google production servers.

On Thu, Nov 17, 2022 at 4:28 PM Christian Huitema <[e-mail]<mailto:[e-mail]>> wrote:


On 11/17/2022 4:15 PM, Martin Thomson wrote:
> How many people have shipped version negotiation and v2 already?
>
> I assume that implementations are using the codepoints for the transport parameter in the draft (0xFF73DB), but the drafts says this:
>
>> When this document is approved, it will request permanent allocation of a codepoint in the 0-63 range to replace the provisional codepoint described above.
>
> IANA are about to make that new allocation, but that might not do good things for interoperability.
>
> We're not changing the v2 version number and v2 *requires* the use of this transport parameter: https://quicwg.org/quic-v2/draft-ietf-quic-v2.html#section-4-2<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquicwg.org%2Fquic-v2%2Fdraft-ietf-quic-v2.html%23section-4-2&data=05%7C01%7Cnibanks%40microsoft.com%7C0b21307c92c24ee5f18c08dac906a08b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638043327575620512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wz2tzGwBJsw7zyflxjdsihvHeZ%2FvFJhb1S48%2Bc9x%2BAY%3D&reserved=0>
>
> Consequently, an implementation that uses the current transport parameter codepoint will not interoperate successfully with an implementation that uses any new transport parameter codepoint.
>
> So, we either allocate a new codepoint for both, or we keep the existing ones.  Which do people prefer?
>
> Or, am I wrong about this?


The way I read it, QUIC-V2 makes a reference to QUIC-VN, which is
documented in the reference section as pointing to
draft-ietf-quic-version-negotiation-13. But I fully expect that the next
QUIC-V2 draft will refer to the updated version of QUIC-VN, and thus to
the final transport parameter.

-- Christian Huitema