Re: draft-30 non-implementable, please

[Jana Iyengar <[e-mail]>]

*A reality check: is _anyone_ planning to drop support for -29? (I've
started a poll for this on Slack. Go respond there.)*

I know Fastly and H2O are not; not until we know that clients have moved
past it.

Martin: We don't "officially" have any particular version; we only have
versions that we decide to run interop testing on. And that is entirely
tied to what people are currently supporting.

There are two issues here:
- What should the interop target be? I propose that we leave this at -29.
- What should happen to the changes in -30? I would argue that we should
make those -30. This point might need some more supporting. My argument is
as follows.

As Nick points out, if it does change interop (despite not intending to),
it's good to know. While interop and wider deployment can be of -29, those
of us implementing and deploying -30 in addition can find these issues.
Also, Kazuho notes, it gives us another version to keep around at the same
time, and it encourages people to support multiple IETF versions.

On the other hand, if you really really don't want another version, then
you cannot implement -30 changes, or you can implement it all and call it
-29. You risk interop issues, but you can't get around it anyway, since you
don't want another version.

On people who might implement from their reading of the drafts alone
without engaging elsewhere and want to interop: Good luck to them.

On Tue, Aug 11, 2020 at 5:12 PM Martin Duke <[e-mail]> wrote:

> The QUIC police are not going to come get anyone if they advertise h3-30.
> Everyone's obviously free to implement what they want. The differences
> between "officially" not having h3-30 and some people doing it anyway, and
> officially having it, and some people choosing not to support it, are quite
> small.
>
> The developers for whom it's trivial to deploy new versions have a
> different perspective, obviously, than those for whom it's hard.
>
> I have three reasons for not wanting a draft-30 interop target, and only
> two of them are selfish.
> 1) Those with a "stable version + latest version" deployment model will
> have trouble interoping if one is -27/-29 and the other is -28/-30, e.g.
> 2) My matrix of which versions are shipping in which maintenance releases,
> and getting all those (one line!) bugfixes into the pipelines, is
> cumbersome.
> 3) If my customers ask me why I'm not supporting draft-30, I'd love to
> point to the implementation note in quic-transport that says we're sticking
> with draft-29.
>
> Meanwhile, I see no advantage whatsoever in a cosmetic change in version.
>
>
>
> On Tue, Aug 11, 2020 at 4:22 PM Kazuho Oku <[e-mail]> wrote:
>
>>
>>
>> 2020年8月12日(水) 7:32 Nick Harper <nharper=[e-mail]>:
>>
>>>
>>>
>>> On Tue, Aug 11, 2020 at 3:00 PM David Schinazi <[e-mail]>
>>> wrote:
>>>
>>>> Hi Dmitri,
>>>>
>>>> Agreed on the point about HTTP/3. All this talk about versions applies
>>>> to both the QUIC wire version (0xff0000xx) and the ALPN value (h3-xx).
>>>>
>>>> I think your view of browsers is wrong, or at least it does not match
>>>> Chrome's model.
>>>> Chrome has tests, and runs these tests any time any change is made to
>>>> the codebase.
>>>> In particular, any time any change is made to any networking code, all
>>>> the QUIC tests are run on every single supported QUIC version.
>>>> Adding a new version that does not have interop-breaking changes
>>>> significantly increases the cost of running these Chrome tests.
>>>> I'll also note that Chrome has deployment costs as well, since we have
>>>> multiple release channels.
>>>> The fact that various Chrome release channels support different QUIC
>>>> versions has already caused some confusion.
>>>>
>>>> I'll also note that Google maintains our QUICHE library, and uses it in
>>>> both Chrome and Google servers.
>>>> All of these share one list of supported QUIC versions..
>>>>
>>>> Because of the points above, your solution does not work for us.
>>>>
>>>> Perhaps I can ask the question differently: what are our options and
>>>> what are the tradeoffs?
>>>> Here's my understanding, please correct me if this doesn't sound right:
>>>>
>>>> I think both of these statements will be true:
>>>> 1) draft-30 will have some non-editorial changes from draft-29
>>>> 2) draft-30 will not have any major interop-breaking changes from
>>>> draft-29
>>>>
>>>> If this is right, then I see four options:
>>>> A) We publish draft-30 with a new wire version, create an interop draft
>>>> / matrix page for it, same as previous drafts
>>>> B) We publish draft-30 with a new wire version, but say that folks
>>>> should only implement -29, and don't create any interop events or entries
>>>> for it
>>>> C) We publish draft-30 without modifying the wire version from -29, and
>>>> then create new interop entries for draft-30
>>>> D) We publish draft-30 without modifying the wire version from -29, and
>>>> reuse the interop entries from draft-29
>>>>
>>>> Now, about the pros and cons of these options:
>>>>
>>>> A) pro: ?
>>>> con: supporting only one of -29 and -30 leads to interop failures when
>>>> one implementation uses -29 and the other uses -30
>>>> con: supporting -29 and -30 simultaneously adds testing and deployment
>>>> costs
>>>>
>>>> B) pro: ?
>>>> con: someone new to QUIC might still implement -30 because the interop
>>>> drafts aren't discoverable from the drafts
>>>>
>>>> C) pro: no interop failures
>>>> pro: no increased test and deployment costs
>>>> con: ?
>>>>
>>>> D) pro: no interop failures
>>>> pro: no increased test and deployment costs
>>>> con: ?
>>>>
>>>> Clearly these pros and cons are biased because I'm not understanding
>>>> everyone's use cases. Can someone please help fill in the question marks
>>>> above?
>>>>
>>>
>>> I disagree that C and D have a pro of "no interop failures". Statement 1
>>> above says that there are non-editorial changes, which means that there
>>> could be subtle changes that result in -29 and -30 behaving differently. i
>>> would list "no interop failures" as a pro for A and B, and replace that as
>>> a pro for C and D with a con of "technical differences between -29 and -30
>>> could be masked by using the same identifier for both".
>>>
>>> I think option B is the best option. We're currently at draft-29 for the
>>> base drafts, but that's only the 19th "implementation draft". There's no
>>> reason -30 needs to be an implementation draft. We've solved this problem
>>> before by designating some, but not all, drafts as implementation drafts,
>>> and I see no reason why that has to change now or why this solution
>>> suddenly no longer works. The concern for option B is a hypothetical one.
>>> Someone new implementing QUIC likely wants to interoperate with other
>>> implementations: if no one else is implementing -30, it would behoove this
>>> new implementor to implement -29.. (If they only care about interop when v1
>>> is published, then it doesn't matter if they implement -30 or -29 right
>>> now.)
>>>
>>
>> I mostly agree to what Nick has stated here.
>>
>> Though as some have pointed out, I do not think it is necessary for us to
>> prohibit people from implementing -30. As Christian says, some doing so
>> would help us grease version negotiation.
>>
>> IMO, all we need to agree is what the interop version is, and I think we
>> have a consensus that it would be -29.
>>
>> Assuming that is the case, what is the problem? If somebody new to QUIC
>> implements -30 and asks the developers of other stacks to support -30, we
>> can tell that person that the interop version is -29, and that there are no
>> breaking changes. Then, for the newly developed stack, it is merely a
>> matter of changing the version number exposed on the wire.
>>
>>
>>>
>>>> David
>>>>
>>>> On Tue, Aug 11, 2020 at 1:35 PM Dmitri Tikhonov <
>>>> [e-mail]> wrote:
>>>>
>>>>> On Tue, Aug 11, 2020 at 01:01:38PM -0700, Matt Joras wrote:
>>>>> > I guess the way I see it is, suppose there is a draft-30 version.
>>>>> > Implementers have 3 choices:
>>>>> > 1. Solely implement -30, dropping support for -29.
>>>>> > 2. Supporting both -29 and -30.
>>>>> > 3. Not implement -30 and staying on -29.
>>>>>
>>>>> As the conversation on Slack is rolling away furiously, I would like
>>>>> to post the mailing list so that this does not fall through the
>>>>> cracks and that people can comment in a manner that less ADD-inducing.
>>>>>
>>>>> First, let's all agree that when we talk about "deploying QUIC ID-30,"
>>>>> we are really talking about HTTP/3.  Agreed?
>>>>>
>>>>> Now, there are three categories of implementers:
>>>>>
>>>>>     1. QUIC as a library (lsquic, picoquic, and so on)
>>>>>     2. QUIC as a client (Firefox, Chrome, etc.)
>>>>>     3. QUIC as a server (Google server, F5, and so on)
>>>>>
>>>>> The first category does not care: a library can support any number of
>>>>> versions and the only ill effect is updating code.
>>>>>
>>>>> The second category should also not care.  Because the browser has
>>>>> the Alt-Svc hint and assuming the said browser uses a library that
>>>>> supports all the recent QUIC versions, this browser can ship support
>>>>> for the new QUIC version as soon as the underlying library supports
>>>>> it.
>>>>>
>>>>> It is the third category that experiences pain: deploying and testing.
>>>>> We can tell it's them because they just sounded off on this thread.
>>>>>
>>>>> The solution for them, then, is simple:  Do not deploy ID-30.  The
>>>>> older browsers will support ID-29.  The newer browsers will support
>>>>> both ID-30 and ID-29.  Sticking with ID-29 deployment leaves you no
>>>>> worse than before.  All you have to do is wait for ID-31, ID-Stable,
>>>>> or maybe even ID-NT, in other words some version that is you are
>>>>> comfortable with and bite the bullet then.
>>>>>
>>>>> >From the looks of it, there are not going to be that many versions
>>>>> released before v1, so bite the bullet you will, sooner or later.
>>>>>
>>>>> Here, I solved your problem.  Let's get back to coding!
>>>>>
>>>>>   - Dmitri.
>>>>>
>>>>
>>
>> --
>> Kazuho Oku
>>
>