Subject: draft-30 non-implementable, please

From: Martin Duke <[email-masked]>
Date: Tue, 11 Aug 2020 09:53:04 -0700

I presume a draft-30 is on its way sometime soon thanks to the hard work of
the editors. If the changes don't require any wire changes or other
interoperability problems, I would prefer that the editors somehow denote
that this is not a wire version -- there would be no 0xff00001e, no h3-30,
etc.

Like many others, I'm shipping this stuff now. The more wire versions there
are, the less chance that a client and server will actually be able to
communicate. By all means create a new version when there are substantive
changes, but otherwise let's just keep things the same.

Thanks

---

From: Matt Joras <[email-masked]>
Date: Tue, 11 Aug 2020 10:25:49 -0700

Is this really something we have to denote in the documents? It seems like
an implementation decision to me. I'd rather keep with the consistency of
revving the version in the draft to match the draft number itself, and
implementers can choose whether or not to actually update their
implementations to use them. We can always "decide", as a community, not to
bother implementing 0xff00001e and h3-30 while still incorporating the
updated text.

Matt Joras

On Tue, Aug 11, 2020 at 9:53 AM Martin Duke <[email-masked]> wrote:

> I presume a draft-30 is on its way sometime soon thanks to the hard work
> of the editors. If the changes don't require any wire changes or other
> Like many others, I'm shipping this stuff now. The more wire versions
> there are, the less chance that a client and server will actually be able
> to communicate. By all means create a new version when there are
> substantive changes, but otherwise let's just keep things the same.
>
> Thanks
>

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 11 Aug 2020 10:45:46 -0700

Completely agree. If -30 is compatible with -29 let's keep the same "on the
wire" versioning so that we can maximize the probability of successful
communication!

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 11 Aug 2020 18:54:19 +0100

On Tue, Aug 11, 2020 at 6:46 PM Ryan Hamilton <[email-masked]> wrote:

> Completely agree. If -30 is compatible with -29 let's keep the same "on
> the wire" versioning so that we can maximize the probability of successful
> communication!
>

Speaking as an individual, the struggle I have is that 29 to 30 is not a
no-op. You can look at the current diff for transport [1] and see that
we're sarig down the barrel of 10 design issues with proposals. So as an
endpoint that implements 30-not-30, if I speak to an endpoint that is
barely-29 and I have issues, what is my recourse? I really don't want to
get into UA sniffing to build in branching code...

Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 11 Aug 2020 18:54:54 +0100

whoops [1]

[1] -
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport&url2=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt

---

From: Martin Duke <[email-masked]>
Date: Tue, 11 Aug 2020 11:03:37 -0700

I am happy to defer to the editors as to whether their change requires
interoperability changes or not. My quick scan of the diff doesn't
immediately reveal anything that would actually cause an issue, but I might
be wrong.

---

From: Ian Swett <[email-masked]>
Date: Tue, 11 Aug 2020 14:13:35 -0400

I'm not aware of anything that I expect to cause interop problems, but the
other editors may have something in mind.  In particular, there are no wire
format changes or new mechanisms that if you don't implement, the
connection fails.

I was thinking we would roll the changes into the existing -29, rather than
shipping -30 as an ALPN and Alt-Svc.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Aug 2020 11:24:41 -0700

If that's true, then supporting draft-30 in picoquic in addition to
draft 29 is just a one-line change. Good way to test version aliasing.

On 8/11/2020 11:13 AM, Ian Swett wrote:
> I'm not aware of anything that I expect to cause interop problems, but
> the other editors may have something in mind.  In particular, there
> are no wire format changes or new mechanisms that if you don't
> implement, the connection fails.
>
> I was thinking we would roll the changes into the existing -29, rather
> than shipping -30 as an ALPN and Alt-Svc.
>
> On Tue, Aug 11, 2020 at 2:04 PM Martin Duke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I am happy to defer to the editors as to whether their change
>     requires interoperability changes or not. My quick scan of the
>     diff doesn't immediately reveal anything that would actually cause
>     an issue, but I might be wrong.
>
>     On Tue, Aug 11, 2020 at 10:55 AM Lucas Pardue
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>         whoops [1]
>
>         [1] -
>         On Tue, Aug 11, 2020 at 6:54 PM Lucas Pardue
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>
>                 Completely agree. If -30 is compatible with -29 let's
>                 keep the same "on the wire" versioning so that we can
>                 maximize the probability of successful communication!
>
>
>             Speaking as an individual, the struggle I have is that 29
>             to 30 is not a no-op. You can look at the current diff for
>             transport [1] and see that we're sarig down the barrel of
>             10 design issues with proposals. So as an endpoint that
>             implements 30-not-30, if I speak to an endpoint that is
>             barely-29 and I have issues, what is my recourse? I really
>             don't want to get into UA sniffing to build in branching
>             code...
>
>             Lucas
>
>

---

From: Martin Duke <[email-masked]>
Date: Tue, 11 Aug 2020 11:54:02 -0700

Christian,

I think the issue is that for many of us a one-line change can take weeks
or months to propagate to the field, so there will be more version
mismatches in the meantime.

I suppose if all h3-30s also support h3-29, there's no issue, but that's a
weird thing to mandate.

On Tue, Aug 11, 2020 at 11:25 AM Christian Huitema <[email-masked]>
wrote:

> If that's true, then supporting draft-30 in picoquic in addition to draft
> 29 is just a one-line change. Good way to test version aliasing.
>>>> On Tue, Aug 11, 2020 at 6:46 PM Ryan Hamilton <[email-masked]>
>>>> <[email-masked]> wrote:
>>>>
>>>>> Completely agree. If -30 is compatible with -29 let's keep the same
>>>>> "on the wire" versioning so that we can maximize the probability of
>>>>> successful communication!
>>>>>
>>>>
>>>> Speaking as an individual, the struggle I have is that 29 to 30 is not
>>>> a no-op. You can look at the current diff for transport [1] and see that

---

From: David Schinazi <[email-masked]>
Date: Tue, 11 Aug 2020 11:56:55 -0700

If there are no interop-breaking changes, then I would much prefer draft-30
to have text stating that 0xff00001e and h3-20 MUST NOT be sent on the wire.
Deploying a new version would take on the order of two months for us, and
also has a non-negligible impact on the environment due to the large amount
of tests we run on all supported versions.

On Tue, Aug 11, 2020 at 11:54 AM Martin Duke <[email-masked]>
wrote:

>> the other editors may have something in mind.  In particular, there are no
>> wire format changes or new mechanisms that if you don't implement, the
>> connection fails.
>>
>>> On Tue, Aug 11, 2020 at 10:55 AM Lucas Pardue <
>>> [email-masked]> wrote:
>>>
>>>> whoops [1]
>>>>
>>>> [1] -
>>>> On Tue, Aug 11, 2020 at 6:54 PM Lucas Pardue <
>>>> [email-masked] <[email-masked]>> wrote:
>>>>
>>>>>

---

From: Matt Joras <[email-masked]>
Date: Tue, 11 Aug 2020 12:38:55 -0700

David and others, why does it matter if the draft specifies a version -30
or not? If you don't feel there's a need to deploy a version -30 in Chrome
and the Google servers, then why bother? Other endpoints will then be
incentivized to keep wire format support for -29, and some may not bother
implementing -30 at all.

That being said I don't particularly care very much. We already support 4
versions and two logical wire formats, and the pain of supporting further
ones is negligible at this point, so we will do whatever keeps us
interoping with the most implementations.

I guess I don't see that this requires any changes to language in the draft
around transport versions.

Matt Joras

On Tue, Aug 11, 2020, 11:57 AM David Schinazi <[email-masked]>
wrote:

> If there are no interop-breaking changes, then I would much prefer
> draft-30 to have text stating that 0xff00001e and h3-20 MUST NOT be sent on
> the wire.
>> I suppose if all h3-30s also support h3-29, there's no issue, but that's
>> a weird thing to mandate.
>>
>>>>> [email-masked] <[email-masked]>> wrote:
>>>>>
>>>>>>
>>>>>> Speaking as an individual, the struggle I have is that 29 to 30 is
>>>>>> not a no-op. You can look at the current diff for transport [1] and see
>>>>>> that we're sarig down the barrel of 10 design issues with proposals. So as
>>>>>> an endpoint that implements 30-not-30, if I speak to an endpoint that is

---

From: David Schinazi <[email-masked]>
Date: Tue, 11 Aug 2020 12:46:36 -0700

The problem is that if the drafts don't say anything, then some folks will
deploy h3-30 and then all others will be forced to choose between doing
expensive useless work and losing interop.
Speaking for the Google implementation, adding a version to the codebase
isn't a lot of engineering work, it's the deployment and testing
infrastructure costs that are really high for us.

On Tue, Aug 11, 2020 at 12:39 PM Matt Joras <[email-masked]> wrote:

> I guess I don't see that this requires any changes to language in the
> draft around transport versions.
>
> Matt Joras
>
>>> I think the issue is that for many of us a one-line change can take
>>> weeks or months to propagate to the field, so there will be more version

---

From: Matt Joras <[email-masked]>
Date: Tue, 11 Aug 2020 13:01:38 -0700

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.

My feeling is that not many implementers will opt for option 1.
Implementations for whom it is easy to add new versions could do 2, and
those for whom it is difficult or there are other considerations preventing
it can do 3. The end result is we have individual implementers choosing or
not choosing to add another version. If e.g. Chrome and Firefox and Safari
opt for option 3, then anyone who wants to maintain interop with them will
not choose option 1.

Adding new special casing language in the draft to add a version "hole" for
30 seems needlessly complicated to me; this feels more like a community
socialization problem than a specification problem.

Matt Joras

On Tue, Aug 11, 2020, 12:46 PM David Schinazi <[email-masked]>
wrote:

>>> Deploying a new version would take on the order of two months for us,
>>> and also has a non-negligible impact on the environment due to the large
>>> amount of tests we run on all supported versions.
>>>
>>>> I suppose if all h3-30s also support h3-29, there's no issue, but
>>>> that's a weird thing to mandate.
>>>>
>>>>>> requires interoperability changes or not. My quick scan of the diff doesn't
>>>>>>>>> Completely agree. If -30 is compatible with -29 let's keep the
>>>>>>>>> same "on the wire" versioning so that we can maximize the probability of

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 11 Aug 2020 13:09:43 -0700

Thanks for kicking this off, Martin. I was hoping to have this conversation
after we shipped -30, but now is fine too.

This is a problem that's happening now, but it's going to keep repeating
for subsequent versions. Hopefully there are very few of those before v1,
but there will be ones after v1 as well. I expect that most deployments are
likely to support at least two versions going forward - the "most
supported" version, and any cutting-edge or experimental versions.

There's going to be a deployed base that uses -29 for a while. Speaking for
Fastly, we intend to support -29 at our servers for the foreseeable future
simply because we expect an increasing number of clients to be speaking
that for a while. I propose that we call -29 the most-supported version.

Given that, implementations that want to can choose to support -30 in
addition. This can be the cutting-edge version.

Keeping the versions separate allows us to exercise this particular split
that I suspect most of us will want to support.

- jana

On Tue, Aug 11, 2020 at 12:47 PM David Schinazi <[email-masked]>
wrote:

>>>>>>> [email-masked] <[email-masked]>> wrote:
>>>>>>>
>>>>>>>>

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 11 Aug 2020 16:16:13 -0400

On Tue, Aug 11, 2020 at 09:53:04AM -0700, Martin Duke wrote:
> If the changes don't require any wire changes or other interoperability
> problems, [...]

A superficial review of diffs of the Invariants and Transport Drafts
reveals:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants&url2=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt

    - One new MUST

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants&url2=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt

    - One new SHOULD
    - One new SHOULD NOT
    - Two new MUSTs
    - One new MUST NOT

I could not spot any wire or interop problems stemming from these, but
that's just me eyeballing this for 20 minutes -- YMMV!

  - Dmitri.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 11 Aug 2020 16:35:14 -0400

> 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.

---

From: David Schinazi <[email-masked]>
Date: Tue, 11 Aug 2020 14:59:32 -0700

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?

David

---

From: Nick Harper <[email-masked]>
Date: Tue, 11 Aug 2020 15:31:53 -0700

> everyone's use cases. Can someone please help fill in the question marks

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.)

>
> David
>
> On Tue, Aug 11, 2020 at 1:35 PM Dmitri Tikhonov <
> [email-masked]> wrote:
>

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Aug 2020 08:22:24 +0900

2020年8月12日(水) 7:32 Nick Harper <nharper=[email-masked]>:

>> In particular, any time any change is made to any networking code, all
>> the QUIC tests are run on every single supported QUIC version.
>> All of these share one list of supported QUIC versions..
>>
>> con: supporting only one of -29 and -30 leads to interop failures when
>> one implementation uses -29 and the other uses -30
> new implementor to implement -29.. (If they only care about interop when v1

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.

-- 
Kazuho Oku

---

From: Martin Duke <[email-masked]>
Date: Tue, 11 Aug 2020 17:12:08 -0700

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 <[email-masked]> wrote:

>>> 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).
>>>
>>> Chrome has tests, and runs these tests any time any change is made to
>>> the codebase.
>>> Perhaps I can ask the question differently: what are our options and
>>> what are the tradeoffs?
>>> 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

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 11 Aug 2020 20:04:28 -0700

*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.

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 11 Aug 2020 20:13:49 -0700

> On Aug 11, 2020, at 8:04 PM, Jana Iyengar <[email-masked]> 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.
> 
> - 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 <[email-masked] <mailto:[email-masked]>> 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. 
> On Tue, Aug 11, 2020 at 4:22 PM Kazuho Oku <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 2020年8月12日(水) 7:32 Nick Harper <nharper=[email-masked] <mailto:[email-masked]>>:
> 
> 
> On Tue, Aug 11, 2020 at 3:00 PM David Schinazi <[email-masked] <mailto:[email-masked]>> 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.
> Perhaps I can ask the question differently: what are our options and what are the tradeoffs?
> 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
> 
> con: supporting only one of -29 and -30 leads to interop failures when one implementation uses -29 and the other uses -30
> con: someone new to QUIC might still implement -30 because the interop drafts aren't discoverable from the drafts
> 
> 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.) 
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 12 Aug 2020 10:09:16 -0500

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=
[email-masked]> wrote:

> 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
>
>
>
>> 2) My matrix of which versions are shipping in which maintenance
>> releases, and getting all those (one line!) bugfixes into the pipelines, is
>> cumbersome.
>>>> On Tue, Aug 11, 2020 at 3:00 PM David Schinazi <
>>>> [email-masked]> wrote:
>>>>
>>>>> Hi Dmitri,
>>>>>
>>>>> A) We publish draft-30 with a new wire version, create an interop
>>>>> draft / matrix page for it, same as previous drafts
>>>>> 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
>>>>>
>>>> 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
>>>> 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
>>> 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..
>>>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 12 Aug 2020 15:35:30 +0000

>  Would that make sense in the Applicability draft?

We already have a section on „Enabling New Versions” in the draft. But I guess we could add more text if someone what’s to write something…

From: QUIC <[email-masked]> on behalf of Spencer Dawkins at IETF <[email-masked]>
Date: Wednesday, 12. August 2020 at 17:10
To: Eric Kinnear <ekinnear=[email-masked]>
Cc: Ryan Hamilton <[email-masked]>, Jana Iyengar <[email-masked]>, Ian Swett <ianswett=[email-masked]>, Matt Joras <[email-masked]>, Nick Harper <nharper=[email-masked]>, Christian Huitema <[email-masked]>, Lucas Pardue <[email-masked]>, David Schinazi <[email-masked]>, IETF QUIC WG <[email-masked]>, Martin Duke <[email-masked]>, Kazuho Oku <[email-masked]>
Subject: Re: draft-30 non-implementable, please

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?

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.

Best,

Spencer

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

On Aug 11, 2020, at 8:04 PM, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Eric

On Tue, Aug 11, 2020 at 5:12 PM Martin Duke <[email-masked]<mailto:[email-masked]>> 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.

On Tue, Aug 11, 2020 at 4:22 PM Kazuho Oku <[email-masked]<mailto:[email-masked]>> wrote:

2020年8月12日(水) 7:32 Nick Harper <nharper=[email-masked]<mailto:[email-masked]>>:

On Tue, Aug 11, 2020 at 3:00 PM David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dmitri,

A) pro: ?

B) pro: ?

David

On Tue, Aug 11, 2020 at 1:35 PM Dmitri Tikhonov <[email-masked]<mailto:[email-masked]>> wrote:

  - Dmitri.

--
Kazuho Oku