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

[Chuck Lever <[e-mail]>]

Two weeks ago, I presented on the status of draft-ietf-nfsv4-rpcrdma-version-two.
The slides are here:

https://datatracker.ietf.org/meeting/interim-2020-nfsv4-01/materials/slides-interim-2020-nfsv4-01-sessa-ietf-107-rpc-rdma-v2.pdf

On slide 18, I described three situations involving Read chunks that do not appear
to be adequately covered by RFC 8166 ("Remote Direct Memory Access Transport for
Remote Procedure Call Version 1"). I'd like to propose modifications to the
rpcrdma-version-two draft to address these cases:


> RPC/RDMA v1 allows a position zero Read chunk to appear in an RDMA_MSG type Call.
> Where does a Responder put the inline portion of such a message?

I propose that in RPC/RDMA version 2, a Responder MUST return RDMA2_ERR_BAD_XDR if
a Requester sends a Read list containing a position zero Read chunk as part of
header type other than RDMA2_NOMSG.


> RPC/RDMA v1 does not explicitly require an RDMA_NOMSG type Call to have a position
> zero Read chunk. Does such a message have gaps? Are they zero-filled?


I propose that in RPC/RDMA version 2, a Responder MUST return RDMA2_ERR_BAD_XDR if
a Requester sends an RDMA2_NOMSG header type whose Read list does not include a
position zero Read chunk.


> 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.


Comments/concerns?

--
Chuck Lever