[tsvwg] Re: [Review requested] draft-collette-sinip-transport-00 (new secure multiplexed transport over IP/UDP)

["C. M. Heard" <[e-mail]>]

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 <[e-mail]> 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
>
>