Has it been considered to add a tunnel prefix header, or more generally a virtual path header to QUIC? That would avoid nested QUIC connections with dual loss control etc. in favor or a simpler virtual routing context that might re-encrypt just the actual QUIC header along the virtual path. This side steps the issue of having an unencrypted inner or outer QUIC connection. Generally allowing unencrypted QUIC is probably a can of Worms, especially wrt. big firewalls.
Kind Regards, Mikkel Fahnøe Jørgensen On 30 September 2020 at 18.22.19, David Schinazi ([email protected]) 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= [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 >> >>
