Re: draft-30 non-implementable, please

[Matt Joras <[e-mail]>]

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