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? Mirja On 20.10.20, 15:23, "Lars Eggert" <[email protected]> wrote: Hi, On 2020-10-20, at 16:13, Mirja Kuehlewind <[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
