RE: QUIC – Will it Replace TCP/IP?

[Scheffenegger, Richard]

>> Microsoft just announced that they are open-sourcing their QUIC stack (under an MIT license).
>>
>> MSQUIC is suitable for application and kernel-use (it will ship as 
>> part of the Windows kernel), so it might be usable in
>
>My understanding was that QUIC focuses purely on userland implementations this is interesting.
>Since understanding how the Windows kernel works is on my ToDo list for next life, can you explain how they do the public crypto operations in the kernel without risking CPU exhaustion attacks (last time I checked, these were expensive).

I have not checked the code in that repository more than casually checking how much work a port as a kernel module in FreeBSD would be. Not checked any details of that implementation. 

>> other kernel contexts (FreeBSD/ONTAP, Linux) as well. The amount of work needed is likely (much) less than porting another QUIC stack that is only meant for user-space use. Also, based on my testing, MSQUIC is amongst the faster and most interoperable stacks.
>>
>> In short, if we wanted to do something with QUIC, MSQUIC would probably a good starting point.
>
>Is there really a demand for kernel based QUIC stacks?

Well, there is certainly demand for Public Cloud storage, and that moves more and more into primary storage space (read: NFS and iSCSI as transport protocols). As public cloud services are accessed via the public internet, the threat model which QUIC tries to address becomes more and more relevant in that space too. While not impossible as user space modules, NFS and iSCSI implementations used for root filesystem access are done in the kernel. Thus I wouldn't be surprised if at least some level of interest exists to do a QUIC prototype in kernel space.

Richard