Re: QUIC – Will it Replace TCP/IP?

Michael Tuexen tuexen at
Wed Apr 29 22:40:55 UTC 2020

> On 30. Apr 2020, at 00:29, Scheffenegger, Richard <Richard.Scheffenegger at> wrote:
>>>> 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 
I agree. I think it is HTTP3/QUIC/UDP compared to HTTP2/TLS 1.3/TCP.
> built on top of that stack. If all that moves to QUIC, these protocols may also be moving there. Certainly when this allows 
Sure. Not sure if there are adaptations needed for moving a protocol from HTTP2 to HTTP3, but you can move all Web traffic to the new stack if it works on the path. If not they fall back to HTTP2/TLS 1.3/TCP, I think.
> 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.
For use cases where you serve data from kernel land...

Best regards
> _______________________________________________
> freebsd-transport at mailing list
> To unsubscribe, send any mail to "freebsd-transport-unsubscribe at"

More information about the freebsd-transport mailing list