Re: [PATCH net-next v2 00/15] net: introduce QUIC infrastructure and core subcomponents

On Tue, Aug 26, 2025, at 5:48 PM, Xin Long wrote:
> Hi, John,
> 
> Feel free to create a thread on [email protected] for this.
> 
> Thanks.

Kicking of the new linux QUIC dev mailing list with this, as requested.

(The last email in netdev is
https://lore.kernel.org/netdev/CADvbK_e9sNbvHSCNuvetOCFY5OQPG99tmZLW=odcRzcN9xK8rQ@mail.gmail.com/,
for reference.)

> On Sun, Aug 24, 2025 at 1:57 PM Xin Long <[email protected]> wrote:
> >
> > On Sat, Aug 23, 2025 at 11:21 AM John Ericson <[email protected]> wrote:
> > >
> > > (Note: This is an interface more than implementation question ---
> > > apologies in advanced if this is not the right place to ask. I
> > > originally sent this message to [0] about the IETF internet draft
> > > [1], but then I realized that is just an alias for the draft
> > > authors, and not a public mailing list, so I figured this would be
> > > better in order to have something in the public record.)
> > >
> > > ---
> > >
> > > I was surprised to see that (if I understand correctly) in the
> > > current design, all communication over one connection must happen
> > > with the same socket, and instead stream ids are the sole
> > > mechanism to distinguish between different streams (e.g. for
> > > sending and receiving).
> > >
> > > This does work, but it is bad for application programming which
> > > wants to take advantage of separate streams while being
> > > transport-agnostic. For example, it would be very nice to run an
> > > arbitrary program with stdout and stderr hooked up to separate
> > > QUIC streams. This can be elegantly accomplished if there is an
> > > option to create a fresh socket / file descriptor which is just
> > > associated with a single stream. Then "regular" send/rescv, or
> > > even read/write, can be used with multiple streams.
> > >
> > > I see that the SCTP socket interface has sctp_peeloff [2] for this
> > > purpose. Could something similar be included in this
> > > specification?

> > Hi, John,
> >
> > That is a bit different. In SCTP, sctp_peeloff() detaches an
> > association/connection from a one-to-many socket and returns it as a
> > new socket. It does not peel off a stream. Stream send/receive
> > operations in SCTP are actually quite similar to how QUIC handles
> > streams in the proposed QUIC socket API.

OK fair enough. sctp_peeloff() was the closest prior art I could find,
but I don't know much about SCTP. Rest assured, I did have the QUIC
semantics in mind. E.g. closing one of these QUIC per-stream peeled off
sockets should close just the stream in question, not the entire
connection.

> > For QUIC, supporting 'stream peeloff' might mean creating a new
> > socket type that carries a stream ID and maps its sendmsg/recvmsg to
> > the 'parent' QUIC socket.

Yes, exactly.

> > But there are details to sort out, like whether the 'parent-child
> > relationship' should be maintained.

What do you mean by this? I assume the answer is that it should be
maintained? e.g. if the connection is closed, then any child per-stream
sockets are also invalidated and must be closed.

> > We also need to consider whether this is worth implementing in the
> > kernel, or if a  similar API could be provided in libquic.

So this is sort of the crux of my argument. If it is in userland, then
any application that wants to act per-stream needs to know about QUIC.
But if it is in kernel, just a a tiny bit of QUIC-aware glue code is to
plug together QUIC-agnostic software, by passing stream sockets to that
software. (You could do it by passing pipes and a little userland
man-in-the-middle using *quic_sendmsg and quic_recvmsg*, of course, but
those extra context switches and copies are rather lousy.)

For what it's worth, I would go further in fact and say that this
"stream peeloff" system call should not just be supported by QUIC, too.
It is very nice today how many code can be agnostic to TCP vs unix
domain sockets, for example. I would ideally want the same thing to be
true with QUIC too, via an "extended unix domain socket" that would
replicate the QUIC state machine(s) just as regular unix domain sockets
replicate the TCP state machine.

I bring up such an "extended unix domain socket" not to indulge in scope
creep, but just to point out that a good litmus test for a new socket
interface is that multiple domains could meaningfully support it, and
that litmus test is met in this case.

Cheers,

John