Re: Why does ATSSS need MPQUIC?

[Behcet Sarikaya <[e-mail]>]

Simple answer is yes you can but don't do it.

Behcet

On Fri, Oct 23, 2020 at 4:57 PM Matt Joras <[e-mail]> wrote:

> 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
>>
>