Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-09

[Chuck Lever <[e-mail]>]

> On May 8, 2017, at 8:35 AM, Tom Talpey <[e-mail]> wrote:
> 
> On 5/4/2017 11:00 AM, Chuck Lever wrote:
>> I've tried to address your concerns, and I changed the segment count
>> limit to document what we know about the current Solaris implementations.
>> I liked the "be conservative in what you send" idea, but I couldn't find
>> a way to work it in that was not awkward.
>> 
>> If this text is OK, I'll submit a fresh I-D revision after WGLC ends on
>> Friday.
> 
> Well that wasn't enough time for me to respond since I was traveling
> from SambaXP in Germany, but the text does look better. The statement
> below makes no requirement on the server.
> 
>> 5.4.2.  Chunk List Complexity
>> ...
>>   To avoid encountering server chunk list complexity limits, NFS
>>   version 4 clients SHOULD follow the below prescriptions when
>>   constructing transport headers:
>> 
>>   o  The Read list can contain either a Position-Zero Read chunk, one
>>      Read chunk with a non-zero Position, or both.
>> 
>>   o  The Write list can contain no more than one Write chunk.
>> 
>>   o  Any chunk can contain up to sixteen RDMA segments.
> 
> I would suggest the following modifications to the above.
> 
>  "In accordance with chunk list processing limits of existing
>   server implementations, NFS Version 4 clients SHOULD maximally
>   follow the below prescriptions when constructing requests to
>   be transported by RPC-over-RDMA. Additionally, NFS Version 4
>   servers SHOULD minimally be prepared to accept and process such
>   requests."

Actually I think "servers MUST be prepared" is appropriate here,
although IMO "clients should follow the below" implies the server
side requirements already. But no harm in making it explicit.


>>   NFS version 4 clients wishing to send more complex chunk lists can
>>   provide configuration interfaces to bound the complexity of NFS
>>   version 4 COMPOUNDs, limit the number of elements in scatter-gather
>>   operations, and avoid other sources of RPC-over-RDMA chunk overruns
>>   at the receiving peer.
>> 
>>   An NFS Version 4 server has some flexibility in how it indicates that
>>   an RPC-over-RDMA Version One message received from an NFS Version 4
>>   client is valid but cannot be processed.  Examples include:
> 
> 
> Strongly suggest deleting the words "has some flexibility" and "Examples
> include". We've already had this discussion, so I will just suggest the
> following.
> 
>  "An NFS Version 4 server SHOULD return one of the following responses
>   to a client which has sent a request containing RPC-over-RDMA chunks
>   which cannot be processed due to exceeding server implementation
>   limits"

Both look fine to me. Spencer, if you're willing, I can replace -10
with a revision that includes these changes.


> Tom.
> 
> 
>>   o  A problem is detected by the transport layer while parsing the
>>      transport header in an RPC Call message.  The server responds with
>>      an RDMA_ERROR message with the err field set to ERR_CHUNK.
>> 
>>   o  A problem is detected during XDR decoding of the RPC Call message
>>      while the RPC layer reassembles the call's XDR stream.  The server
>>      responds with an RPC reply with its "reply_stat" field set to
>>      MSG_ACCEPTED and its "accept_stat" field set to GARBAGE_ARGS.
>> 
>>   After receiving one of these errors, an NFS version 4 client SHOULD
>>   NOT retransmit the failing request, as the result would be the same
>>   error.  It SHOULD immediately terminate the RPC transaction
>>   associated with the XID in the reply.
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever