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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <cb74facd-aa28-4c9d-b05f-84be3a135b20@app.fastmail.com>
Date: Sat, 23 Aug 2025 11:20:31 -0400
From: "John Ericson" <mail@...nericson.me>
To: "Xin Long" <lucien.xin@...il.com>, "network dev" <netdev@...r.kernel.org>
Cc: draft-lxin-quic-socket-apis@...f.org
Subject: Re: [PATCH net-next v2 00/15] net: introduce QUIC infrastructure and core
 subcomponents

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

John

[0]: draft-lxin-quic-socket-apis@...f.org
[1]: https://datatracker.ietf.org/doc/draft-lxin-quic-socket-apis/
[2]: https://man7.org/linux/man-pages/man3/sctp_peeloff.3.html