[nfsv4] NFS over QUIC

bfields@fieldses.org Thu, 03 September 2020 21:52 UTC

Return-Path: <bfields@fieldses.org>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 64C6C3A12B7 for <nfsv4@ietfa.amsl.com>; Thu, 3 Sep 2020 14:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fieldses.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DQrjL67f5jFP for <nfsv4@ietfa.amsl.com>; Thu, 3 Sep 2020 14:52:47 -0700 (PDT)
Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97F83A12B4 for <nfsv4@ietf.org>; Thu, 3 Sep 2020 14:52:46 -0700 (PDT)
Received: by fieldses.org (Postfix, from userid 2815) id 0543E1C25; Thu, 3 Sep 2020 17:52:43 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org 0543E1C25
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1599169963; bh=zAqWKfUeoEES9zp0RnX2+mvHU+omspjePHNhk4XbnkY=; h=Date:To:Cc:Subject:From:From; b=Q3P1hmAVQoFD4b6Rs2iWMV2pePRtTiNsUyKtEus8aCEN6DlNrdQ33QgWWRGlHLEwo FmXR35ndu1FBYwokSJGvluUKIDmmXbUkI2DTit6Tpe9exV0k3uL1iVSd4rjdrZ4BEQ z/4mdK4WnH5KU5rwSTtfOe1OE8jyyDCfpLjscK0I=
Date: Thu, 03 Sep 2020 17:52:42 -0400
To: linux-nfs@vger.kernel.org, nfsv4@ietf.org
Cc: stfrench@microsoft.com, Chuck Lever <chuck.lever@oracle.com>
Message-ID: <20200903215242.GA4788@fieldses.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
From: bfields@fieldses.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/uHB9oTTyVvOTY36OF7phhI9pqlQ>
Subject: [nfsv4] NFS over QUIC
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2020 21:52:49 -0000

I've been thinking about what might be required for NFS to run over

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:


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:


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:


	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?