Subject: Re: I-D Action: draft-ietf-quic-v2-01.txt

From: Bill Gage <[email-masked]>
Date: Tue, 25 Jan 2022 17:11:55 +0000

How about using the same strategy as planned OS releases - e.g. there will be a new rolling release of the QUIC spec at least once a year on March 21 that, as a minimum, greases the codepoints and salts. Officially, the new release could be identified with a label such as something like "v01-2022r01" with the actual on-wire version number generated as a hash of that label.

If necessary, each new release (and associated on-wire version number) could also come with a pre-determined sunset date after which it is not expected to be supported by deployed implementations. Having a calendar for QUIC updates may also help with planning for all interested parties.

The label "v01" refers to the RFC of the base protocol, i.e. RFC 9000. If there is a real change to the base protocol, it can be given the label "v02" in a new RFC.

Cheers ... 

/bill

> Hi Martins,
> 
> Wearing no hats.
> 
> 
> On Sat, 22 Jan 2022, 02:05 Martin J. Dürst, <[email-masked]> wrote:
>> 
>> Hello everybody,
>>
>> The following concern just popped up in my mind:
>>
>> Some people (in particular the press,...) may take version numbers very
>> seriously. Reading "QUIC version 2", my guess is that there might be
>> articles saying things such as "Quic already is at version 2" or "Quic
>> version 1 is outdated, use version 2", and so on.
>>
>> Everybody on this list (including me) of course understands that such
>> stuff is completely wrong, and it's easy for people who want to figure
>> out that it's wrong. Nevertheless, there are quite a few instances where
>> version numbers have taken a life of their own.
>>
>> The purpose of this mail is that everybody consider the risk of the
>> above "misunderstandings". If we are fine with that risk, then let's go
>> with "version 2". If we have some doubts, it would be easy to change the
>> version number to something else, such as 1.1, or 0.99, or A.bc, or
>> whatever.
>>
> 
> Whatever moniker we chose, I think there will be some part of the
> population that will be surprised and read something more into it than what
> the specification is attempting to do or solve. Personally I think QUIC 1.1
> would be a very bad name though.
> 
> I've lost count of the times I've seen a comment like "I've only just heard
> about HTTP/2, and now there is an HTTP/3?".
> 
> This spec will help exercise our version negotiation mechanism and help
> prevent stagnation and ossification. In some sense we are trying to build
> an evergreen transport, to borrow a w3c term [1].  Perhaps people should
> become accustomed to a new version of QUIC being released on a regular
> cycle, so that implementer and operators build out the processes needed to
> stay compatible and up-to-date.
> 
> Cheers
> Lucas

---

From: Martin Duke <[email-masked]>
Date: Thu, 27 Jan 2022 14:19:31 -0800

Regular version releases are the most obvious way to grease the version.

However, before we get around to v3 I'd like to ship Version Aliasing
instead:
https://datatracker.ietf.org/doc/draft-duke-quic-version-aliasing/

It's a more comprehensive solution that carries security and privacy
benefits as well.

On Tue, Jan 25, 2022 at 9:12 AM Bill Gage <Bill.Gage=
[email-masked]> wrote:

> How about using the same strategy as planned OS releases - e.g. there will
> be a new rolling release of the QUIC spec at least once a year on March 21
> that, as a minimum, greases the codepoints and salts. Officially, the new
> release could be identified with a label such as something like
> "v01-2022r01" with the actual on-wire version number generated as a hash of
> that label.
>
> If necessary, each new release (and associated on-wire version number)
> could also come with a pre-determined sunset date after which it is not
> expected to be supported by deployed implementations. Having a calendar for
> QUIC updates may also help with planning for all interested parties.
>
> The label "v01" refers to the RFC of the base protocol, i.e. RFC 9000. If
> there is a real change to the base protocol, it can be given the label
> "v02" in a new RFC.
>
> Cheers ...
>
> /bill
>
> > Hi Martins,
> >
> > Wearing no hats.
> >
> >

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 31 Jan 2022 12:19:54 -0600

FWIW, I REALLY want to encourage the working group to consider a formal
statement of how long QUIC versions would be "supported", as in "if someone
finds a serious problem, we'll work to fix it", as Bill proposed below.

That might not be the right thing to do, and might even be impossible to
commit to in an all-volunteer organization, but I think we have to realize
that in the absence of a formal statement of support durations, a lot of
people are going to assume that any QUIC version would be supported by the
working group "forever".

Best,

Spencer

On Thu, Jan 27, 2022 at 4:20 PM Martin Duke <[email-masked]> wrote:

>> How about using the same strategy as planned OS releases - e.g. there
>> will be a new rolling release of the QUIC spec at least once a year on
>> March 21 that, as a minimum, greases the codepoints and salts. Officially,
>> the new release could be identified with a label such as something like

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 31 Jan 2022 18:32:05 +0000

Hey,

Responding to the theme of this thread, as an individual.

I think it's a laudable goal to have scheduled releases and up-front
support cycles. However, I fear what that requires is switching the group
from a QUIC standards development and maintenance transport WG into a
software and hardware delivery and operations group. Yes, if there are
problems found in QUIC protocol versions or extensions, we should seek to
fix them. However, I think it is a major challenge to attempt coordination
across the diverse set of implementations and platforms where QUIC already
runs. It also seems the antithesis of our goal in building an
ossification-resistant protocol that encourages evolution and
experimentation.

Instead, as an individual, I would rather the WG continue to build robust
versioning capabilities that allow the community to drive their own
evolution. I trust the WG will, if required, make judgement calls on the
right time and circumstances to deprecate IETF versions of QUIC. I would
not be optimistic that we can drive deployments to change their supported
versions just because we said so.

Cheers,
Lucas

---

From: Christian Huitema <[email-masked]>
Date: Mon, 31 Jan 2022 11:41:01 -0800

> versions just because we said so.

We have a fairly light weight extension capability, which very much 
"allows the community to drive their own evolution". There is already 
quite a bit of experience with that: delayed acks, datagrams, multipath 
were all tested and deployed using the extension mechanism. Given that 
mechanism, I wonder what the versioning capability brings. I can think 
of two approaches:

1) Spring clean-up. When the season comes, the WG looks at the various 
extensions that have been negotiated, and decides which one should be 
considered "mainline" in the new version. There is some merit to that, 
but the same result could probably be achieved by standardizing popular 
extensions.

2) Define new packet formats, incompatible with the initial version. I 
think that's the real value of versioning.

For example, we may want to define a version of QUIC that's more secure 
than the current one, more robust against attacks during the handshake 
-- something like Martin & David's "protected initials" draft. That 
requires changing format and handling of initial packets, i.e., defining 
a new version.

-- Christian Huitema

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 31 Jan 2022 13:41:09 -0600

> versions just because we said so.

I'm sympathetic to this point of view (and this is one of the reasons I was
thinking that this might not be possible in an all-volunteer organization
in my previous comment), but I thought it was useful to ask, because if
anything like an expiration date was possible to establish, I'm sure that
talking about that sooner rather than later would make establishing an
expiration date much easier.

I didn't say this out loud, but I think my suggestion makes much more sense
if something like Bill's suggestion about telling people to expect a new
release each year, on some date, even if it's just bumping the version
number and salts, was also happening. If the notice of a new QUIC version
number included something like "you can expect to use this protocol version
for the next three years without worrying about obsolescence", or whatever
the right thing to say is.

Do The Right Thing, of course!

Best,

Spencer

---

From: David Schinazi <[email-masked]>
Date: Mon, 31 Jan 2022 12:03:40 -0800

I'm not sure what the value here is. CDN deployments will base which QUIC
versions they support on what their customers are asking for, and client
deployments will base their versions on what servers support. Neither will
make decisions based on what IETF recommends.

David

On Mon, Jan 31, 2022 at 11:42 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> I'm sympathetic to this point of view (and this is one of the reasons I
> was thinking that this might not be possible in an all-volunteer
> organization in my previous comment), but I thought it was useful to ask,
> because if anything like an expiration date was possible to establish, I'm
> sure that talking about that sooner rather than later would make
> establishing an expiration date much easier.
>
> I didn't say this out loud, but I think my suggestion makes much more
> sense if something like Bill's suggestion about telling people to expect a
> new release each year, on some date, even if it's just bumping the version

---

From: Bill Gage <[email-masked]>
Date: Mon, 31 Jan 2022 20:24:13 +0000

Hello Lucas and Spencer -

Just to clarify, when I said "there could be a new rolling release of the QUIC spec at least once a year on March 21 that, as a minimum, greases the codepoints and salts", I didn't mean to imply a change to the existing WG mode of operation - RFCs would continue to be issued as soon as the WG completes its various work items.

What I meant was, to ensure an ossification-resistant protocol, there could be a new QUIC RFC issued periodically that greases the codepoints and salts *if there had been no other relevant updates* to the base QUIC spec in the intervening period.

The new RFC would use a release label similar to "v01-2022r01" that would be an indicator of the base version of the protocol ("v01", currently RFC 9000) and the greased codepoints/salts ("2022r01"). If the version identifier isn't changed, then it is an indication that the RFC refers only to greased codepoints/salts, Hopefully this would avoid the confusion of using a linear sequence of version identifiers for updates that only refer to greased codepoints/salts.

Clearly, the actual on-wire version number would always be changed.

Cheers ...

> From: Spencer Dawkins at IETF
> Sent: Monday, January 31, 2022 2:41 PM

> 
> On Mon, Jan 31, 2022 at 12:32 PM Lucas Pardue <[email-masked]> wrote:
>> Hey,
>> 
>> I think it's a laudable goal to have scheduled releases and up-front support cycles. 
>> However, I fear what that requires is switching the group from a QUIC standards 
>> development and maintenance transport WG into a software and hardware delivery 
>> and operations group. Yes, if there are problems found in QUIC protocol versions 
>> or extensions, we should seek to fix them. However, I think it is a major 
>> challenge to attempt coordination across the diverse set of implementations and 
>> platforms where QUIC already runs. It also seems the antithesis of our goal in 
>> building an ossification-resistant protocol that encourages evolution and 
>> experimentation. 
>> 
>> Instead, as an individual, I would rather the WG continue to build robust versioning 
>> capabilities that allow the community to drive their own evolution. I trust the 
>> WG will, if required, make judgement calls on the right time and circumstances 
>> to deprecate IETF versions of QUIC. I would not be optimistic that we can drive 
>> deployments to change their supported versions just because we said so.
> 
> I'm sympathetic to this point of view (and this is one of the reasons I was thinking 
> that this might not be possible in an all-volunteer organization in my previous 
> comment), but I thought it was useful to ask, because if anything like an 
> expiration date was possible to establish, I'm sure that talking about that 
> sooner rather than later would make establishing an expiration date much easier. 
> 
> I didn't say this out loud, but I think my suggestion makes much more sense if 
> something like Bill's suggestion about telling people to expect a new release 
> each year, on some date, even if it's just bumping the version number and salts, 
> was also happening. If the notice of a new QUIC version number included 
> something like "you can expect to use this protocol version for the next three 
> years without worrying about obsolescence", or whatever the right thing to say 
> is. 
>

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 31 Jan 2022 20:43:18 +0000

Hey,

Still speaking as an invidiual:

On Mon, 31 Jan 2022, 20:24 Bill Gage, <[email-masked]> wrote:

> Just to clarify, when I said "there could be a new rolling release of the
> QUIC spec at least once a year on March 21 that, as a minimum, greases the
> codepoints and salts", I didn't mean to imply a change to the existing WG
> mode of operation - RFCs would continue to be issued as soon as the WG
> completes its various work items.
>
> What I meant was, to ensure an ossification-resistant protocol, there
> could be a new QUIC RFC issued periodically that greases the codepoints and
> salts *if there had been no other relevant updates* to the base QUIC spec
> in the intervening period.
>
> The new RFC would use a release label similar to "v01-2022r01" that would
> be an indicator of the base version of the protocol ("v01", currently RFC
> 9000) and the greased codepoints/salts ("2022r01"). If the version
> identifier isn't changed, then it is an indication that the RFC refers only
> to greased codepoints/salts, Hopefully this would avoid the confusion of
> using a linear sequence of version identifiers for updates that only refer
> to greased codepoints/salts.
>

I appreciate the point but I think it risks putting a large burden on both
the process of standards and the endpoints that want to use QUIC. All in
the name of trying to convince people not to do the lazy thing. But lazy is
as lazy does.

If the whole thing could be automated, it wouldn't be so bad. But that is
unfeasible and we require too many humans in the loop, which doesn't scale
well.

Personally I'd rather invest my engineering time in the things that benefit
end users more directly. Ossification is a risk to end users but there are
other forms mitigations that require less human hours.

Cheers
Lucas

> support cycles.
> was thinking
> sense if

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 31 Jan 2022 21:23:53 +0000

*   I'm not sure what the value here is. CDN deployments will base which QUIC versions they support on what their customers are asking for, and client deployments will base their versions on what servers support. Neither will make decisions based on what IETF recommends.

Like David, I don’t see the point.  Once you factor in the reality of multiple parties involved, including perhaps the QUIC runtime provider, it seems that you’re asking for a “QIUC flag day” everyone year.

Ugh, no thanks.