I've been thinking about what might be required for NFS to run over QUIC. Also cc'ing Steve French in case he's thought about this for CIFS/SMB. I don't have real plans. For Linux, I don't even know if there's a kernel QUIC implementation planned yet. QUIC uses TLS so we'd probably steal some stuff from the NFS/TLS draft: https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-tls/ For example, section 4.3, which explains how to authenticate on top of an already-encrypted session, should also apply to QUIC. QUIC runs over UDP, so I think all that would be required to negotiate support would be to attempt a QUIC connection to port 2049. The "Transport Layers" section in the NFS RFCs: https://tools.ietf.org/html/rfc5661#section-2.9 requires transports support reliable and in-order transmission, forbids clients from retrying a request unless a connection is lost, and forbids servers from dropping a request without closing a connection. I'm still vague on how those requirements interact with QUIC's connection management and 0-RTT reconnection. https://www.ietf.org/id/draft-ietf-quic-applicability-07.txt looks useful, as a guide for applications running over QUIC. It warns that connections can time out fairly quickly. For timely callbacks over NFS sessions, that means we need the client to ping the server regularly. Sounds like that's what they do for HTTP/QUIC to make server push notifications work: https://tools.ietf.org/html/draft-ietf-quic-http-09#section-5 HTTP clients are expected to use QUIC PING frames to keep connections open. Servers SHOULD NOT use PING frames to keep a connection open. A client SHOULD NOT use PING frames for this purpose unless there are responses outstanding for requests or server pushes. QUIC allows multiple streams per connection--I wonder how we might use that. RFC 5661 justifies the requirement for an ordered transport with: Ordered delivery simplifies detection of transmit errors, and simplifies the sending of arbitrary sized requests and responses via the record marking protocol. So as long as we don't try to split a single RPC among streams, I think we're OK. Would a stream per session slot be reasonable? I'm not sure what the cost of a stream is. Do we need to add a new universal address type so the protocol can specify QUIC endpoints when necessary? (For server-to-server-copy, pnfs file layouts, fs_locations, etc.) All QUIC needs is an IP address and maybe a port, so maybe the existing UDP/TCP addresses are enough? --b.
