Re: quic in-kernel implementation?

From: Stefan Metzmacher <metze@samba.org>
To: "Steve French" <smfrench@gmail.com>, "Aurélien Aptel" <aaptel@suse.com>
Cc: Alexander Ahring Oder Aring <aahringo@redhat.com>,
	Network Development <netdev@vger.kernel.org>,
	linux-nfs <linux-nfs@vger.kernel.org>,
	CIFS <linux-cifs@vger.kernel.org>,
	Leif Sahlberg <lsahlber@redhat.com>,
	Steven Whitehouse <swhiteho@redhat.com>
Subject: Re: quic in-kernel implementation?
Date: Tue, 8 Jun 2021 09:36:27 +0200	[thread overview]
Message-ID: <35352ef0-86ed-aaa5-4a49-b2b08dc3674d@samba.org> (raw)
In-Reply-To: <CAH2r5msMBZ5AYQcfK=-xrOASzVC0SgoHdPnyqEPRcfd-tzUstw@mail.gmail.com>

Am 08.06.21 um 05:04 schrieb Steve French:
> On Mon, Jun 7, 2021 at 11:45 AM Aurélien Aptel <aaptel@suse.com> wrote:
>>
>> Alexander Ahring Oder Aring <aahringo@redhat.com> writes:
>>> as I notice there exists several quic user space implementations, is
>>> there any interest or process of doing an in-kernel implementation? I
>>> am asking because I would like to try out quic with an in-kernel
>>> application protocol like DLM. Besides DLM I've heard that the SMB
>>> community is also interested into such implementation.
>>
>> Yes SMB can work over QUIC. It would be nice if there was an in-kernel
>> implementation that cifs.ko could use. Many firewall block port 445
>> (SMB) despite the newer version of the protocol now having encryption,
>> signing, etc. Using QUIC (UDP port 443) would allow for more reliable
>> connectivity to cloud storage like azure.
>>
>> There are already multiple well-tested C QUIC implementation out there
>> (Microsoft one for example, has a lot of extra code annotation to allow
>> for deep static analysis) but I'm not sure how we would go about porting
>> it to linux.
>>
>> https://github.com/microsoft/msquic
> 
> Since the Windows implementation of SMB3.1.1 over QUIC appears stable
> (for quite a while now) and well tested, and even wireshark can now decode it, a
> possible sequence of steps has been discussed similar to the below:
> 
> 1) using a userspace port of QUIC (e.g. msquic since is one of the more tested
> ports, and apparently similar to what already works well for QUIC on Windows
> with SMB3.1.1) finish up the SMB3.1.1 kernel pieces needed for running over
> QUIC

Instead of using userspace upcalls directly, it would be great if we could hide
behind a fuse-like socket type, in order to keep the kernel changes in fs/cifs (and other parts)
tiny and just replace the socket(AF_INET) call, but continue to use a
stream socket (likely with a few QUIC specific getsockopt/setsockopt calls).

It would also allow userspace applications like Samba's smbclient and smbd
to use it that way too.

> 2) then switch focus to porting a smaller C userspace implementation of
> QUIC to Linux (probably not msquic since it is larger and doesn't
> follow kernel style)
> to kernel in fs/cifs  (since currently SMB3.1.1 is the only protocol
> that uses QUIC,
> and the Windows server target is quite stable and can be used to test against)> 3) use the userspace upcall example from step 1 for
> comparison/testing/debugging etc.
> since we know the userspace version is stable

With having the fuse-like socket before it should be trivial to switch
between the implementations.

> 4) Once SMB3.1.1 over QUIC is no longer experimental, remove, and
> we are convinced it (kernel QUIC port) works well with SMB3.1.1
> to servers which support QUIC, then move the quic code from fs/cifs to the /net
> tree

The 4th step would then finally allocate a stable PF_QUIC which would be
ABI stable.

metze