Re: Transport parameters for version negotiation and v2

[David Schinazi <[e-mail]>]

It's both simplest and safest to change both, I'd suggest doing that.
David

On Wed, Nov 30, 2022 at 10:30 PM Martin Thomson <[e-mail]> wrote:

> Right, thanks for reviving this.
>
> My sense is that the best approach here is to make a clean break and get a
> new codepoints for BOTH the version negotiation transport parameter and the
> v2 version.
>
> Though deployments can change, they probably won't change atomically
> enough to avoid real negotiation failure.
>
> On Thu, Dec 1, 2022, at 06:25, Martin Duke wrote:
> > 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
> >>>
> >>> ____
>
>