Re: draft-30 non-implementable, please

[Jana Iyengar <[e-mail]>]

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 <[e-mail]>
wrote:

> 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 <[e-mail]> wrote:
>
>> 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 <[e-mail]>
>> 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.
>>> 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 <[e-mail]>
>>> wrote:
>>>
>>>> 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 <[e-mail]>
>>>> 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 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 <[e-mail]>
>>>>> 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 <
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>> On Tue, Aug 11, 2020 at 6:54 PM Lucas Pardue <
>>>>>>> [e-mail] <[e-mail]>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 11, 2020 at 6:46 PM Ryan Hamilton <[e-mail]>
>>>>>>>> <[e-mail]> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>