Re: draft-30 non-implementable, please

[Matt Joras <[e-mail]>]

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