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 <[email protected]> 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 >
