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