Re: draft-30 non-implementable, please

[Spencer Dawkins at IETF <[e-mail]>]

I apologize in advance for asking, but when will it make sense for the QUIC
community to have a document that explains these version deployment
strategies?

Would that make sense in the Applicability draft?

I kind of expect that it's better to deal with this sooner, rather than
later, because as HTTP/3-QUIC is more widely deployed, there will be more
implementers who aren't closely tied to the QUIC specification community,
so more likely to make sub-optimal guesses about what is best to do.

I should mention that I'm concerned about this because I'm aware of a major
cellular handset vendor who implemented "Standard TCP" in the late 1990s,
and we all know that TCP Slow Start/Congestion Avoidance wasn't in STD 7,
so they didn't implement that ... and I don't know why new implementers
would be more aware of what the IETF community is thinking about now than
they were 20 years ago. Fortunately, someone stopped those guys before they
shipped.

Do the right thing, of course.

Best,

Spencer

On Tue, Aug 11, 2020 at 10:14 PM Eric Kinnear <ekinnear=
[e-mail]> wrote:

>
>
> On Aug 11, 2020, at 8:04 PM, Jana Iyengar <[e-mail]> wrote:
>
>
> *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.
>
>
> I’d also second what David says below, from Dimitri’s categories, the
> other two categories (1) library and (2) client also do things like testing
> and deploying as well. Many of the same problems arise for our testing and
> deployment as are present for Chrome.
>
> So the risk in my mind is much along the lines of what Martin outlined
> here: it really boils down to the number of possible combinations that we
> end up with. We stated at one point that we wanted to do some large scale
> testing and get deployment experience from several implementations.
>
> It seems like plan works best when the maximum number of people can talk
> to the maximum number of other people. The more we make different draft
> versions that don’t all speak to each other because of generally-one-line
> bugfixes that need to coordinate, the less we end up succeeding at that
> goal.
>
> So while it’s great to not drop -29 support, I think letting -30 be
> “legit” -30 yet not making a new intro draft for it would be a good
> balance. We all keep -29 deployed and if you on-the-side want to support
> -30 then that’s okay too.
>
> Thanks,
> Eric
>
>
>
> 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.
>>
>
> I’d tend to strongly agree with all three of these points.
>
>
>> 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
>>>
>>
>