I believe that the mailserver is swallowing my emails to the mailing list, and has since April, so we’ll see if this makes it anywhere.
I’d love to have conversations about why we’d be doing multipath in the transport, as opposed to at some higher layer. There are some good reasons, but listing them out (and determining which are requirements vs just where it has been done in the past) would be good. -=R From: QUIC <[email protected]> on behalf of Spencer Dawkins at IETF <[email protected]> Date: Tuesday, October 20, 2020 at 6:54 AM To: Mirja Kuehlewind <[email protected]> Cc: "Flinck, Hannu (Nokia - FI/Espoo)" <[email protected]>, Florin Baboescu <[email protected]>, WG Chairs <[email protected]>, Lucas Pardue <[email protected]>, Lars Eggert <[email protected]>, IETF QUIC WG <[email protected]> Subject: Re: Uploaded "Why Multipath QUIC?" for 2020-10 Interim Chiming in with Mirja, On Tue, Oct 20, 2020 at 8:46 AM Mirja Kuehlewind <[email protected]<mailto:[email protected]>> wrote: Hi Lars, Spencer, Florin, and I are about to figure out how to handle the different slides we have now. Sorry for the hassle. There is parallel discussion in 3GPP so we are a bit last minute here. In ATSSS one of the Ses stands for Splitting where the general idea is to be able to split traffic of one e2e flow over an 3GPP and a non-3GPP network path. There is a mode for traffic aggregation with would require simultaneous use of both paths. All proposed solutions in 3GPP are based in some way on the use of QUIC tunnels on each network path. If only QUICv1 without MP support would be available and two independent tunnels would be used, some reordering logic in the tunnel endpoints would be needed. This is currently not in scope for 3GPP. Therefore a QUICv1 solution without support for using multiple paths simultaneously would not support Splitting. Current view in 3GPP is that this is not sufficient and therefore solutions that reply on MP-QUIC to support reordering between multiple paths are preferred. I guess the requirement for this are that QUIC can use two paths simultaneously and that data send within one stream but transmitted over two paths are delivered in order. Not sure what other requirements you would expect to see at this stage? That's certainly the point of my slides on steering modes, and that's more obvious because of the edits I made after feedback from the chairs. At 20km view, two of the four Phase 1 steering modes *could* be handled using QUICv1 with migration, but the third needs simultaneous paths in some cases, and the fourth needs it in all cases. All four of the additional Phase 2 steering modes need simultaneous paths. So, there are probably details, but that's the requirement from my perspective. Best, Spencer Mirja On 20.10.20, 15:23, "Lars Eggert" <[email protected]<mailto:[email protected]>> wrote: Hi, On 2020-10-20, at 16:13, Mirja Kuehlewind <[email protected]<mailto:[email protected]>> wrote: > I though we are at the step where we collect use cases in order to understand if there is a need and support for MP support in QUIC exactly. But in order to have a discussion on this, we need to hear from the proponents of those use cases what functionality they are missing in QUICv1. > (rather than going into requirement for how multipath support would be realized). But requirements are not about the "how" - that was exactly Lucas' point. Requirements are about "what". So statements along the lines of "my use case requires the ability to fail over a connection to a different path", etc. would be informative. Saying "my use case requires draft-deconinck" less so (for example). > We could also talk more about requirement but I think that’s better for a later discussion and would maybe need more than 5 minutes. I'd hope not? Because if there is a long shopping list of requirements for new QUIC functionality to support a particular use case, that'd look to some as a pretty convincing case that maybe QUIC isn't really a suitable starting technology. Thanks, Lars
