Re: quic in-kernel implementation?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Jun 8, 2021, at 3:36 AM, Stefan Metzmacher <metze@xxxxxxxxx> wrote:
> 
> Am 08.06.21 um 05:04 schrieb Steve French:
>> On Mon, Jun 7, 2021 at 11:45 AM Aurélien Aptel <aaptel@xxxxxxxx> wrote:
>>> 
>>> Alexander Ahring Oder Aring <aahringo@xxxxxxxxxx> 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.

That's interesting as a development scaffold.

However, IMO the interesting part of QUIC for us is transport
layer security. NFS already has TLS via RPC-over-TLS, and we
intend to have a full in-kernel implementation soon. Using a
user-space transport protocol implementation is likely to be
an unacceptable step backwards in terms of performance for us.
NFS connections are long-lived, no benefit at all from the
special 0-RTT mechanisms.

I hope the end goal is to have a full in-kernel implementation
of QUIC at some point, otherwise I don't see Linux QUIC ever
being on par with current TCP performance for a kernel
consumer.


>> 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.

Although switching QUIC implementations is a cool trick for
rapid prototyping, I'm unclear on the eventual user benefit
of it.


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

--
Chuck Lever







[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux