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 > <[email protected]> wrote: > > > > > > On Wed, Sep 30, 2020 at 5:24 AM Olivier Bonaventure > > <[email protected]> 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 > >>
