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

[spencer shepler <[e-mail]>]

Chuck,

I am fine with taking Tom's suggestion and we can move the updated draft
forward.

Spencer


On Mon, May 8, 2017 at 6:58 AM Chuck Lever <[e-mail]> wrote:

>
> > 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
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>