Dear Lars, all, In the view of the recently scheduled QUIC WG Virtual Meeting on 22nd October related to this topic, what is the plan on this LS?
Thanks, Waqar. From: QUIC <[email protected]> On Behalf Of David Schinazi Sent: 01 October 2020 17:18 To: Lars Eggert <[email protected]> Cc: QUIC WG <[email protected]> Subject: Re: 2nd draft, response to Liaison Statement, "LS on ATSSS Phase 2Requirements to IETF QUIC Working Group" CAUTION: This email originated from outside of the organization. Thanks Lars, the second draft looks good to me. David On Thu, Oct 1, 2020 at 7:36 AM Spencer Dawkins at IETF <[email protected]<mailto:[email protected]>> wrote: Hi, Lars, On Thu, Oct 1, 2020 at 6:20 AM Lars Eggert <[email protected]<mailto:[email protected]>> wrote: Hi, thanks for the feedback! Below is an updated draft that attempts to incorporate it. Please feel free to send further 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 being under active investigation for the pre-IETF "Google QUIC" protocol, several 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. This is much improved. Perhaps it is also worth pointing out that (just like 3GPP) the IETF and QUIC working group are contribution-driven, so any timeline estimates depend on people contributing to the work, and the IETF is open to participation from anyone who can contribute to the work. On Qn-2: The QUIC WG is chartered to provide an encrypted transport protocol. An option to disable encryption will hence not be standardized. That's the right answer to the question the QUIC working group was asked. I agree that a different question might have gotten a different answer, but you're not a mind reader ... Best, Spencer Kind regards, Mark Nottingham, Lucas Pardue and Lars Eggert, QUIC Working Group chairs
