Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"

[David Schinazi <[e-mail]>]

To add to what Ian said, I really think that the following
statement from the draft reply is an overstatement:
<<[multipath support for QUIC] was part of the original
charter due to its inclusion in the pre-IETF
"Google QUIC" protocol>>. As Ian said, the team was
considering it but it never made it into the protocol.
Perhaps you could rephrase it to something like:
<<[multipath support for QUIC] was part of the original
charter because it was of interest to authors of the
pre-IETF "Google QUIC" protocol>>?

Other than that, the reply looks good to me, I think
figuring out whether to do multipath in the WG, and
refusing to remove encryption are the right calls.

David

On Wed, Sep 30, 2020 at 7:49 AM Ian Swett <ianswett=
[e-mail]> wrote:

>
>
> On Wed, Sep 30, 2020 at 5:24 AM Olivier Bonaventure <
> [e-mail]> wrote:
>
>> Lars, Lucas and Mark,
>> >
>> > FYI, below is a draft of our intended response to the Liaison Statement
>> "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group" which we
>> intend to send next week.
>> >
>> > Please feel free to send comments.
>> >
>> > Thanks,
>> > Lars, Lucas and Mark
>> >
>> > --
>> >
>> > Thank you for the update on your progress and your questions. Please
>> find our
>> > responses below.
>> >
>> > On Qn-1: The future of multipath support for QUIC is currently under
>> active
>> > discussion in the IETF QUIC working group. While it was part of the
>> original
>> > charter due to its inclusion in the pre-IETF "Google QUIC" protocol,
>> several
>>
>> I'm very surprised by this sentence. It gives the impression that
>> multipath was a feature of Google's proprietary QUIC protocol. My
>> understanding based on the public documents that Google released and the
>> source code is that multipath was considered by Google as they reserved
>> one bit in the header to indicate multipath but that this was not fully
>> implemented nor tested within Google QUIC. If Google had a specification
>> of multipath QUIC, I'd be very interested in seeing this document.
>>
>
> There was a design and part of an implementation, but it was never
> completed because there were no customers for it and it added substantial
> complexity.
>
> IETF QUIC has changed quite a bit from Google QUIC, so I think basing any
> design on the more recent multipath proposal(
> draft-deconinck-quic-multipath-05
> <https://tools.ietf.org/html/draft-deconinck-quic-multipath-05>) would be
> a better starting point.
>
>>
>> My understanding of the initial charter discussion was that multipath
>> was a desired feature by many of the participants in the initial charter.
>>
>> > participants have argued during the last year that QUIC's connection
>> migration
>> > support is sufficient for the majority of our use cases, and that
>> full-blown
>> > support for multipath QUIC should consequently be abandoned as a WG
>> deliverable.
>> > Other WG participants remain of the opinion that multipath support for
>> QUIC is
>> > very important. Due to this active ongoing discussion, we do not have
>> an estimate
>> > at this time whether WG drafts for multipath QUIC will be available in
>> 1Q2021.
>> >
>> > On Qn-2: The QUIC WG is chartered to provide an encrypted transport
>> protocol.
>> > An option to disable encryption will hence not be standardized.
>> >
>> > Kind regards,
>> > Mark Nottingham, Lucas Pardue and Lars Eggert, QUIC Working Group chairs
>> >
>>
>> Best regards,
>>
>>
>> Olivier
>>
>>