On Wed, Sep 30, 2020 at 2:35 PM Martin Thomson <[email protected]> wrote:
> 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. > Sure! I was just objecting to the existing text that overstated Google's involvement in multipath. Saying that there was WG interest sounds fine by me. David 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 > > >> > >
