Simple answer is yes you can but don't do it. Behcet
On Fri, Oct 23, 2020 at 4:57 PM Matt Joras <[email protected]> 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 <[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 >> >
