Re: Transport parameters for version negotiation and v2

[Martin Duke <[e-mail]>]

I don't want to lose this thread, as this is a quite important thing to
resolve. I personally would prefer to keep the version number constant, but
it's not all clear to me that it's acceptable to deployed implementations.

On Mon, Nov 21, 2022 at 5:06 AM Nick Banks <[e-mail]> wrote:

> 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]>
> 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
>
>