Re: [nfsv4] Clean up for rpcrdma-version-two Read chunks

[Chuck Lever <[e-mail]>]

Hi Dave-

I've mocked up the proposed changes in the Editor's Copy of this document.
The changes add similar requirements for NOMSG and Reply chunks.

Here is the full text:

https://chucklever.github.io/i-d-rpcrdma-version-two/draft-ietf-nfsv4-rpcrdma-version-two.html


Here is the raw text of the new requirements:

Requirement A: the Read list must be in ascending order

Added to Section 4.3.5

   If a Responder receives a Read list whose RDMA segment position
   values do not appear in monotonically increasing order, it MUST
   discard the message without processing it and respond with an
   RDMA2_ERROR message with the rdma_xid field set to the XID of the
   malformed message and the rdma_err field set to RDMA2_ERR_BAD_XDR.
   If a Requester receives a Read list whose RDMA segment position
   values do not appear in monotonically increasing order, it MUST
   discard the message without processing it and terminate the RPC
   transaction that corresponds to the XID value in the rdma_xid
   field of the malformed message.


Requirement B: NOMSG is the only header type that can carry a PZRC or Reply chunk

Added to Section 4.4.3

   If a Responder receives an RPC-over-RDMA message that carries a
   Position Zero Read chunk and whose RDMA2_F_RESPONSE flag is clear but
   the message does not use the RDMA2_NOMSG header type, it MUST discard
   that message without processing it and respond with an RDMA2_ERROR
   message with the rdma_xid field set to the XID of the malformed
   message and the rdma_err field set to RDMA2_ERR_BAD_XDR.  When a
   Requester receives an RPC-over-RDMA message that carries a Reply
   chunk and whose RDMA2_F_RESPONSE flag is set but the message does not
   use the RDMA2_NOMSG header type, it MUST discard that message without
   processing it and terminate the RPC transaction corresponding to the
   XID value in the message's rdma_xid field.


Requirement C: A NOMSG header type with a non-empty Read list must have a PZRC

Added to Section 6.3.2

   When a Responder receives an RDMA2_NOMSG header type with a non-empty
   Read list that does not carry a Position Zero Read chunk, it MUST
   discard that message without processing it and send an RDMA2_ERROR
   message with the rdma_err field set to RDMA2_ERR_BAD_XDR.  When a
   Requester receives an RDMA2_NOMSG header type with an empty Reply
   chunk, it discards that message and terminates the RPC transaction
   represented by the XID value in the rdma_xid field of the malformed
   message.


I have not addressed this one yet:

> On May 4, 2020, at 12:13 PM, Chuck Lever <[e-mail]> wrote:
> 
>> RPC/RDMA v1 does not prevent or prohibit overlapping Read chunks. Is the correct
>> response ERR_CHUNK?
> 
> A protocol change would be needed to totally prevent the expression of overlapping
> Read chunks. Maybe it's a little too late to address that in RPC/RDMA version 2.
> 
> I propose that in RPC/RDMA version 2, a Responder MUST return RDMA2_ERR_BAD_XDR if
> a Requester sends a Read list with chunks whose offsets and lengths result in the
> same message byte position appearing in more than one Read chunk.

There is still a need, IMO, for the receiver to watch out for overlapping
read segments when there is more than one Read chunk in the list. As an
example:

Given an RPC Call with two normal Read chunks, each chunk has one read
segment, presented in ascending order of position:

Inline
Length: 512 bytes

Read segment A
Position: byte 32
Length: 128 bytes

Read segment B
Position: byte 144
Length: 64 bytes

Read segment B's starting position (144) is inside Read segment A.

Perhaps a way to address overlaps would be to change the segment position
value to mean the byte offset within the inline body. A value of zero
still would have the special meaning of "this chunk replaces the inline
body".


--
Chuck Lever