Re: Uploaded "Why Multipath QUIC?" for 2020-10 Interim

[Spencer Dawkins at IETF <[e-mail]>]

Chiming in with Mirja,

On Tue, Oct 20, 2020 at 8:46 AM Mirja Kuehlewind <
[e-mail]> 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" <[e-mail]> wrote:
>
>     Hi,
>
>     On 2020-10-20, at 16:13, Mirja Kuehlewind <mirja.kuehlewind=
> [e-mail]> 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
>
>