Re: Why does ATSSS need MPQUIC?

[Matt Joras <[e-mail]>]

It's gotten somewhat buried in the various threads and updates that have
flown around about ATSSS, but I found the following draft pretty helpful
for explaining the various ways it would work for them, including multiple
QUIC connections:
https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00.
Section 7.1.4 covers that case specifically.

Matt Joras

On Fri, Oct 23, 2020 at 2:39 PM David Schinazi <[e-mail]>
wrote:

> Hi everyone,
>
> Thanks for the great conversation yesterday.
> Thinking about it more, I'm realizing I might be
> misunderstanding something: why does ATSSS
> need MPQUIC at all? Why not simply use two
> separate QUIC connections, one per interface?
> The only difference is that the scheduler would
> live right on top of QUIC instead of inside QUIC.
> If I recall the history of MPTCP correctly, the
> scheduler was placed in the kernel because of
> the cost of context switching from userspace to
> kernelspace. This consideration doesn't apply
> to QUIC since most QUIC implementations are in
> userspace. I'll note that for this to work, we'd need
> a way to transmit path information - that could use
> a separate protocol, or a small extension to QUIC -
> but either way that sounds like much less
> complexity than MPQUIC.
>
> Thanks,
> David
>