Chiming in with Mirja, On Tue, Oct 20, 2020 at 8:46 AM Mirja Kuehlewind < [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]> wrote: > > Hi, > > On 2020-10-20, at 16:13, Mirja Kuehlewind <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 > >
