Re: draft-30 non-implementable, please

[Eric Kinnear <[e-mail]>]

> 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] <mailto:[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] <mailto:[e-mail]>> wrote:
> 
> 
> 2020年8月12日(水) 7:32 Nick Harper <nharper=[e-mail] <mailto:[e-mail]>>:
> 
> 
> On Tue, Aug 11, 2020 at 3:00 PM David Schinazi <[e-mail] <mailto:[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] <mailto:[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