Hi Rick, inline with the comment below. Can you maybe explain what the problems are that this protocol addresses but QUIC doesn’t? What are the differences to QUIC? And could those also be addressed with a QUIC extension?
Mirja From: "C. M. Heard" <[email protected]> Date: Tuesday, 24. February 2026 at 03:19 To: Rick Collette <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [tsvwg] Re: [Review requested] draft-collette-sinip-transport-00 (new secure multiplexed transport over IP/UDP) Greetings, The I-D states that SIN targets environments requiring a kernel implementation. This seems to be the key motivation. I therefore ask: what significant features of SIN would a QUIC kernel implementation fail to provide? If there aren't any, it seems that the effort would be better spent on kernel implementations of QUIC. I understand that a QUIC kernel implementation exists for Linux: https://github.com/lxin/quic https://www.ietf.org/archive/id/draft-lxin-quic-socket-apis-02.html Thanks and regards, Mike Heard On Mon, Feb 23, 2026 at 2:13 PM Rick Collette <[email protected]<mailto:[email protected]>> wrote: Hi TSVWG (cc QUIC), I’d like review and venue guidance for a new individual draft: https://datatracker.ietf.org/doc/draft-collette-sinip-transport/00/ What it is (one paragraph): SIN/IP is a secure, multiplexed transport designed to run either directly over IP (SIN/IP native) or encapsulated over UDP (SIN/UDP), with connection IDs for migration, AEAD-protected packets, stream multiplexing, and a goal of being practical both in user space and (eventually) kernel-resident environments. What I’m looking for: Venue / scope: Is TSVWG the right place for discussion, or should this be steered elsewhere (QUIC, another WG/area, or independent stream)? Wire image & extensibility: Does the versioning / frame layout / extension approach look ossification-resistant enough? Anything obviously missing for evolvability? Handshake & security properties: Are the stated cryptographic assumptions coherent (keys, transcript binding, anti-replay, downgrade prevention), and are there MUST-level requirements you’d expect to see called out? Deployability: For the UDP encapsulation path, do NAT rebinding, path migration, and middlebox realities look workable as described? Any “this will break in the real internet” red flags? Congestion control story: Is the CC/pacing guidance sufficient for v00, or are there baseline requirements you’d want before taking this further? Specific feedback format that helps most: “Blockers” (things that must change) “Should” improvements (next revision) “Nice-to-have” / future work If you’re willing to take a look, comments by March 8, 2026 (any timezone) would be hugely appreciated. I’ll roll feedback into a -01 quickly and summarize changes on-list. Thanks, Rick Collette
