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

[karen deitke <[e-mail]>]

On 5/3/2017 12:00 AM, Tom Talpey wrote:
>> 5.4.2.  Complexity Considerations
>>
>>     The RPC-over-RDMA Version One protocol does not place any limit on
>>     the number of chunks or segments that may appear in the Read or Write
>>     lists.  However, for various reasons NFS version 4 server
>>     implementations often have practical limits on the number of chunks
>>     or segments they are prepared to process in one message.
>>
>>     These implementation limits are especially important when Kerberos
>>     integrity or privacy is in use [RFC7861].  GSS services increase the
>>     size of credential material in RPC headers, forcing more frequent use
> GSS payloads don't always force this, I'd suggest "potentially requiring" or similar
> softened text.
>
>>     of Position-Zero Read chunks and Reply chunks.  This can increase the
>>     complexity of chunk lists independent of the NFS version 4 COMPOUND
>>     being conveyed.
>>
>>     To avoid encountering server chunk list complexity limits, NFS
>>     version 4 clients SHOULD restrict their RPC-over-RDMA Version One
>>     messages to simple combinations of chunks:
> Again, "restrict" may be too strong. If the client is certain that a certain chunk list
> is acceptable, it's perfectly OK for it to send it. Suggest the following rules being
> cast as "safe" or at least "following the Internet Principles" as "conservative in
> what you send".
>
>>     o  The Read list contains no more than one Position-Zero Read chunk
>>        and one Read chunk with a non-zero Position.
>>
>>     o  The Write list contains no more than one chunk.
>>
>>     o  The inline threshold restricts the number of segments that may
>>        appear in either list.
>>
>>     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 peer.
> Good.
>
>>     An NFS Version 4 server has some flexibility in how it indicates that
>>     an RPC-over-RDMA Version One message constructed by an NFS Version 4
>>     client is valid but cannot be processed.  Examples include:
>>
>>     o  A problem is detected at the transport layer (i.e., during
>>        transport header processing).  The server returns an RDMA_ERROR
>>        message with the err field set to ERR_CHUNK.
>>
>>     o  A problem is detected during XDR decoding of the request (e.g.,
>>        during re-assembly of the RPC Call message by the RPC layer).  The
>>        server returns an RPC reply with its "reply_stat" field set to
>>        MSG_ACCEPTED and its "accept_stat" field set to GARBAGE_ARGS.
>>
>>     o  A problem is detected in the Upper Layer (i.e., by the NFS version
>>        4 implementation).  The server sends an NFS reply with a status of
> The two previous bullets used "returns" while this uses "sends". Intentional?
>
>>        NFS4ERR_RESOURCE.
>>
>>     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.
> Now this is interesting. ERR_CHUNK and GARBAGE_ARGS are clear, but I
> thought NFS4ERR_RESOURCE is generally retryable. So, how does the client
> determine this error is actually from the RDMA encoding, and not retry?
> This protocol should not require another protocol to change existing behavior.
>
> Tom.
>
>
Good point about the NFS4ERR_RESOURCE error.  Other than that, I like 
this change.
Karen