RE: QUIC – Will it Replace TCP/IP?
Richard.Scheffenegger at netapp.com
Wed Apr 29 22:29:44 UTC 2020
>>> 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
>So that may be a use case for the NFS/TLS/TCP implementation, which is ongoing?
Absolutely. Also don't forget, that NFSv4 features transport signing and encryption on its layer (krb5i[ntegrity], krp5p[rivacy]) but these are relatively expensive operations, as not able to divert to a TLS offload engine. The AES processor extensions help, but with the move of the data through the processor.
>> 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
>My impression was that QUIC use cases are a lot in the area where the data you want to serve is in userland, not in kernel land like serving disk content.
You can also see QUIC as the successor of the HTTP/TLS/TCP protocol bundle. Some storage protocols (S3, CDMI, Swift) are built on top of that stack. If all that moves to QUIC, these protocols may also be moving there. Certainly when this allows your web-application to run in places it couldn't otherwise because of DPI...
On the server side, your sendfile() usecase may be quite relevant in that space again for performance.
More information about the freebsd-transport