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

[Ian Swett <[e-mail]>]

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