Re: [nfsv4] [Technical Errata Reported] RFC8166 (6528)

[Chuck Lever III <[e-mail]>]

Sorry for the delay, I wasn't sure where to begin further conversation
on this errata.


> On Apr 12, 2021, at 12:40 PM, RFC Errata System <[e-mail]> wrote:
> 
> The following errata report has been submitted for RFC8166,
> "Remote Direct Memory Access Transport for Remote Procedure Call Version 1".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6528
> 
> --------------------------------------
> Type: Technical
> Reported by: David Noveck <[e-mail]>
> 
> Section: 4.2.4
> 
> Original Text
> -------------
> A Requester MUST NOT send an RPC-over-RDMA header with the RDMA_ERROR
> procedure.  A Responder MUST silently discard RDMA_ERROR procedures

Stated as a co-author of this document, I agree that this text is
problematic for version negotiation, which uses the RDMA_ERROR
procedure/header type.

One vote for "verified".


> Corrected Text
> --------------
> An RDMA_ERROR header cannot be sent without an assurance that, the receiver 
> has posted a receive operation which its sending will satisfy.  In most cases, 
> this means that a Requester (i.e. one sending RPC Calls) MUST NOT send an 
> RPC-over-RDMA header with the RDMA_ERROR procedure.  Similarly, a Responder 
> (i.e. one sending RPC Replies) MUST silently discard RDMA_ERROR procedures.

I don't recall that the issue that prompted the addition of the
original text was the requirement for a posted Receive. That
might be slightly revisionist.

Though it is true sending an RDMA_ERROR when there is no Receive
waiting will likely result in loss of connection, I think the
typical scenario is that RDMA_ERROR is in response to a previous
message; thus missing a Receive would be an implementation bug.

"In most cases," is not appropriate with MUST/MUST NOT. We could
stipulate that the exact cases where these requirements hold is
when sending ERR_CHUNK. These requirements do not hold for ERR_VERS.


> However, in the case of providing an RDMA_ERROR headers containing an error 
> code of ERR_VERS, such a schema is not realizable, since there is no way for
> a receiver who does not support a particular version, to determine whether 
> an RPC Call or Reply is being sent, leaving the receiver uncertain as to whether 
> it is being Addressed as a Requester or a Responder, leaving it unable to
> participate in version negotiation.

The particular issue is that either:

- the Sender of the message with the unsupported version might be
using a procedure of the new protocol version that is not supported
in the protocol version the Receiver supports, or

- the Sender of the message with the unsupported version might be
using a procedure that does not bear an RPC message or any other
indication of message direction.

Thus the Receiver would not be able to determine the direction of
the incoming message.

I'm not convinced that RFC 8166 Section 4.2 is an appropriate place
to explain this reasoning. (Stating it here in the errata is OK).
The above could be dropped in the Corrected text.


> In the case of version errors, the
> implementation is to rely on the assumption that forward direction requests 
> are being done and reserve direction requests only done once the version is
> properly negotiated.

Shorter:

"For the purpose of version negotiation, the receiver is to assume
that reverse-direction operation is started only once the connection's
transport protocol version has been fixed using forward direction
operations."

One problem with this is that reverse-direction operation is defined
in a separate RFC (8167).


> As a result, such messages MUST NOT be sent by the 
> client and MUST be silently discarded by servers.

I'd like to confirm that what the reporter intended in the second
sentence above was "client" and "servers" and not "Requester" and
"Responders".


> Notes
> -----
> Even if one feels that this is not an appropriate correction, the existing text must be fixed somehow.   In assuming that the terms Requester and Responder can be used this way in this context is likely to result in some implementers concluding that version errors can never be sent while other might be unabble to coonclude that given the effort expended in the spec to make such errors be interpretable by anf rpc-over-rdma version.
> 
> 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. 
> 
> --------------------------------------
> RFC8166 (draft-ietf-nfsv4-rfc5666bis-11)
> --------------------------------------
> Title               : Remote Direct Memory Access Transport for Remote Procedure Call Version 1
> Publication Date    : June 2017
> Author(s)           : C. Lever, Ed., W. Simpson, T. Talpey
> Category            : PROPOSED STANDARD
> Source              : Network File System Version 4
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG

--
Chuck Lever