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

On Thu, 13 Feb 2020 at 11:19, RFC Errata System
<rfc-editor@rfc-editor.org> wrote:
>
> 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 <davenoveck@gmail.com>
>
> 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

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.

>    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
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4