Subject: [nfsv4] [Technical Errata Reported] RFC5661 (5982)

From: RFC Errata System <[email-masked]>
Date: Thu, 13 Feb 2020 07:57:37 -0800 (PST)

The following errata report has been submitted for RFC5661,
"Network File System (NFS) Version 4 Minor Version 1 Protocol".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5982

--------------------------------------
Type: Technical
Reported by: David Noveck <[email-masked]>

Section: 2.10.6.1.3.1

Original Text
-------------
   If a requester sent a Sequence operation with a slot ID and sequence
   ID that are in the reply cache but the replier detected that the
   retried request is not the same as the original request, including a
   retry that has different operations or different arguments in the
   operations from the original and a retry that uses a different
   principal in the RPC request's credential field that translates to a
   different user, then this is a false retry.  When the replier detects
   a false retry, it is permitted (but not always obligated) to return
   NFS4ERR_FALSE_RETRY in response to the Sequence operation when it
   detects a false retry.

Corrected Text
--------------
   If a requester sent a Sequence operation with a slot ID and sequence
   ID that are in the reply cache but the replier detected that the
   retried request is not the same as the original request, including a
   retry that was issued with a different XID or has different operations 
   or different arguments in the operations from the original and a retry 
   that uses a different principal in the RPC request's credential field 
   that translates to a different user, then this is a false retry.  When 
   the replier detects a false retry, it is permitted (but not always 
   obligated) to return NFS4ERR_FALSE_RETRY in response to the Sequence 
   operation when it detects a false retry

Notes
-----
The existing text can be read as requiring checksumming of all requests to foreclose the possibility of not noticing a false retry, which can result in data corruption.  This can be a
significant performance consideraation in the processing of WRITE requests and could undercut the benefits of directly placing data to be written which is one of the impotant goals of RPC-over-RDMA.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5661 (draft-ietf-nfsv4-minorversion1-29)
--------------------------------------
Title               : Network File System (NFS) Version 4 Minor Version 1 Protocol
Publication Date    : January 2010
Author(s)           : S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 13 Feb 2020 12:45:07 -0500

> "Network File System (NFS) Version 4 Minor Version 1 Protocol".

The XID requirement is a new one, and is significant on the wire
change for clients. It puts us back in the distasteful situation we
had in NFSv3 where we mix RPC level and NFS level semantics. In
particular it is problematic in the multi-path failover case, where we
want to replay the NFS COMPOUND on a different RPC transport after the
first path failed: XIDs are per-transport in the Linux client.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: David Noveck <[email-masked]>
Date: Fri, 14 Feb 2020 06:12:20 -0500

>
> The XID requirement is a new one,

It is newly mentioned in rfc5661 but it is not a new requirement, since it
is inherent on the fact that nfsv4 is layered on top of RPC.

and is significant on the wire
> change for clients.

Are there really clients that don't bother to generate unique XID's? I
hadn't heard of them.

It puts us back in the distasteful situation we
> had in NFSv3 where we mix RPC level and NFS level semantics.

Distasteful or not, nfsv4.1 is layered on top of RPC and that is unlikely
to change.

In
> first path failed:

I believe that means we have to reject this erratta report. I'll do that.

XIDs are per-transport in the Linux client

They are per-transport everywhere.