Feedback-ID: i82e14979:Fastmail
MIME-Version: 1.0
References: 
 <CAHJ_QM5nmekodRLQ+7te9+4mgXOVGHtZAE5HUxn6OJ_GaDX9oQ@mail.gmail.com>
In-Reply-To: 
 <CAHJ_QM5nmekodRLQ+7te9+4mgXOVGHtZAE5HUxn6OJ_GaDX9oQ@mail.gmail.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Mon, 23 Feb 2026 18:18:11 -0800
Message-ID: 
 <CACL_3VGHcxrJq_j=PbEVv_qL9Yhi=F9P1Tdc0-3=UESThdHcig@mail.gmail.com>
To: Rick Collette <rcollet@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007e3367064b8880b2"
Message-ID-Hash: PV5TB5RHLCSG4S6A5HJJMOPKKY7M7MJR
CC: tsvwg@ietf.org, quic@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Btsvwg=5D_Re=3A_=5BReview_requested=5D_draft-collette-sinip-tran?=
 =?utf-8?q?sport-00_=28new_secure_multiplexed_transport_over_IP/UDP=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tsvwg/k1k-MnE9J3ritV6ykbbmFaUrBxI>

--0000000000007e3367064b8880b2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM Rick Collette <rcollet@gmail.com> w=
rote:

> Hi TSVWG (cc QUIC),
>
> I=E2=80=99d 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=E2=80=99m 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=E2=80=99d expect t=
o see
> called out?
>
> Deployability: For the UDP encapsulation path, do NAT rebinding, path
> migration, and middlebox realities look workable as described? Any
> =E2=80=9Cthis will break in the real internet=E2=80=9D red flags?
>
> Congestion control story: Is the CC/pacing guidance sufficient for
> v00, or are there baseline requirements you=E2=80=99d want before taking =
this
> further?
>
> Specific feedback format that helps most:
>
> =E2=80=9CBlockers=E2=80=9D (things that must change)
>
> =E2=80=9CShould=E2=80=9D improvements (next revision)
>
> =E2=80=9CNice-to-have=E2=80=9D / future work
>
> If you=E2=80=99re willing to take a look, comments by March 8, 2026 (any
> timezone) would be hugely appreciated. I=E2=80=99ll roll feedback into a =
-01
> quickly and summarize changes on-list.
>
> Thanks,
> Rick Collette
>
>

--0000000000007e3367064b8880b2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Greetings,<div><br></div><div>The I-D sta=
tes that SIN targets environments requiring a kernel implementation. This s=
eems to be the key motivation.<br><br>I therefore ask: what significant fea=
tures of SIN would a QUIC kernel implementation fail to provide?<br><br>If =
there aren&#39;t any, it seems that the effort would be better spent on ker=
nel implementations of QUIC.</div><div><br></div><div>I understand that a Q=
UIC kernel implementation exists for Linux:<br><br><a href=3D"https://githu=
b.com/lxin/quic">https://github.com/lxin/quic</a><br><br><a href=3D"https:/=
/www.ietf.org/archive/id/draft-lxin-quic-socket-apis-02.html">https://www.i=
etf.org/archive/id/draft-lxin-quic-socket-apis-02.html</a><br><br>Thanks an=
d regards,<br><br>Mike Heard</div><div><br></div><div>On Mon, Feb 23, 2026 =
at 2:13=E2=80=AFPM Rick Collette &lt;<a href=3D"mailto:rcollet@gmail.com">r=
collet@gmail.com</a>&gt; wrote:</div></div><div class=3D"gmail_quote gmail_=
quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi TSVWG=
 (cc QUIC),<br>
<br>
I=E2=80=99d like review and venue guidance for a new individual draft:<br>
<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-collette-sinip-transport/=
00/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/=
draft-collette-sinip-transport/00/</a><br>
<br>
What it is (one paragraph):<br>
SIN/IP is a secure, multiplexed transport designed to run either<br>
directly over IP (SIN/IP native) or encapsulated over UDP (SIN/UDP),<br>
with connection IDs for migration, AEAD-protected packets, stream<br>
multiplexing, and a goal of being practical both in user space and<br>
(eventually) kernel-resident environments.<br>
<br>
What I=E2=80=99m looking for:<br>
<br>
Venue / scope: Is TSVWG the right place for discussion, or should this<br>
be steered elsewhere (QUIC, another WG/area, or independent stream)?<br>
<br>
Wire image &amp; extensibility: Does the versioning / frame layout /<br>
extension approach look ossification-resistant enough? Anything<br>
obviously missing for evolvability?<br>
<br>
Handshake &amp; security properties: Are the stated cryptographic<br>
assumptions coherent (keys, transcript binding, anti-replay, downgrade<br>
prevention), and are there MUST-level requirements you=E2=80=99d expect to =
see<br>
called out?<br>
<br>
Deployability: For the UDP encapsulation path, do NAT rebinding, path<br>
migration, and middlebox realities look workable as described? Any<br>
=E2=80=9Cthis will break in the real internet=E2=80=9D red flags?<br>
<br>
Congestion control story: Is the CC/pacing guidance sufficient for<br>
v00, or are there baseline requirements you=E2=80=99d want before taking th=
is<br>
further?<br>
<br>
Specific feedback format that helps most:<br>
<br>
=E2=80=9CBlockers=E2=80=9D (things that must change)<br>
<br>
=E2=80=9CShould=E2=80=9D improvements (next revision)<br>
<br>
=E2=80=9CNice-to-have=E2=80=9D / future work<br>
<br>
If you=E2=80=99re willing to take a look, comments by March 8, 2026 (any<br=
>
timezone) would be hugely appreciated. I=E2=80=99ll roll feedback into a -0=
1<br>
quickly and summarize changes on-list.<br>
<br>
Thanks,<br>
Rick Collette<br>
<br>
</blockquote></div></div>

--0000000000007e3367064b8880b2--