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

[Martin Thomson <[e-mail]>]

Wasn't it of interest to the working group? I mean, a Google's interest is relevant, but only to the extent that it contributed to the overall interest in the feature.

On Thu, Oct 1, 2020, at 02:21, David Schinazi wrote:
> 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
> >>