Subject: Why does ATSSS need MPQUIC?

From: David Schinazi <[email-masked]>
Date: Fri, 23 Oct 2020 14:18:26 -0700

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

---

From: Matt Joras <[email-masked]>
Date: Fri, 23 Oct 2020 14:56:25 -0700

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 26 Oct 2020 10:43:59 -0500

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

Behcet