Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-03 review

[David Noveck <[e-mail]>]

I think the better alternative is to document the ambiguity and ask people
to live with it.  Version One's error handling is broken and it doesn't seem
as though it can be fixed without changing the XDR, and we've decided that
all
such changes are to bump the version number.

The idea is to ask the sender not to set the credit value and the receiver
not
to interpret it.

The problem with restricting when this is sent is that it assumes, that if
you receive a message, you can tell if it is a request or a reply.  For a
well-formed
message that can be determined, but the idea here is we are dealing with a
message that is so messed up  that you can't even XDR the transport header.

In we now look at section 5.5.2 and look at the examples there:

an invalid value in the rdma_proc field

Without that, you can't even parse the header so, you don't where to look
for the call/reply inidication.

an RDMA_NOMSG message that has no chunk lists

Here, there is no payload to look at.

or the contents of the rdma_xid field might not match the contents of
the XID field in the accompanying RPC message.

In this case, you can determine which you have.


On Mon, May 23, 2016 at 10:10 AM, Chuck Lever <[e-mail]>
wrote:

>
> > On May 20, 2016, at 3:15 PM, Chuck Lever <[e-mail]> wrote:
> >
> >
> >> On May 20, 2016, at 2:51 PM, Karen <[e-mail]> wrote:
> >>
> >>
> >>
> >> On 5/20/16 12:44 PM, Chuck Lever wrote:
> >>>> On May 20, 2016, at 2:30 PM, Karen <[e-mail]> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 5/20/16 10:41 AM, Chuck Lever wrote:
> >>>>>>
> >>>>>> 4.1
> >>>>>>
> >>>>>> "When message direction is not fully determined by context"
> >>>>>>
> >>>>>> "fully determined by context" thats confusing, what does that
> really mean? I think this means when the rdma header does not directly
> indicate if the message is a call or reply, but the wording is confusing.
> >>>>> That means that in some cases the receiver can guess
> >>>>> accurately which direction the message was going, based
> >>>>> on the context of the operation, even without having
> >>>>> an RPC message payload.
> >>>>>
> >>>>> I'm open to suggestions.
> >>>>>
> >>>>> I think some prefer that the document simply state that
> >>>>> direction is always unknown in cases where an RPC
> >>>>> message payload is not present. That kind of opens a
> >>>>> can of worms with RDMA_ERROR, which is needed to report
> >>>>> that the client does not support backward direction
> >>>>> operation.
> >>>> I don't think that it can always absolutely be clear which direction
> without the RPC header. Or am I misunderstanding RPC payload? I'm taking
> that to mean the RPC header, but maybe you are referring to the NFS data in
> the rpc payload?
> >>> "Context" here means that if the receiver can tell
> >>> by other means (like, there are no other outstanding
> >>> operations). So no, it's not always going to be clear.
> >>> In those cases, direction is not known.
> >> I don't think there is ever a 100% way to know the direction without
> the rpc header's call or reply field.
> >
> > I don't think what I wrote contradicts that statement, but
> > it does allow latitude for innovation to close this hole
> > in other ways.
> >
> >
> >> Even if there is an outstanding request, and it is for the xid that is
> defined in the rdma header, being that the xid is not unique between client
> and server, there still exists, though extremely small, a possiblity that
> this is a new request that just so happens to have the same xid and is not
> actually the reply to an outstanding operation.
> >
> > The only case in RPC-over-RDMA Version One where this is
> > a concern is RDMA_ERROR. The other two valid procs are
> > RDMA_NOMSG and RDMA_MSG, and both of those have RPC
> > message payloads.
> >
> > When a client receives an RDMA_ERROR, that normally means
> > one of its forward requests had a problem.
> >
> > Typical RPC-over-RDMA Version One client implementations
> > don't send an error to a server due to a problem with a
> > forward reply. We can probably say the same about a
> > server sending an RDMA_ERROR to a client in response
> > to a bad backward reply. (And, rfc5666bis could be
> > enhanced to suggest or require that requesters don't
> > send RDMA_ERROR in response to a bogus reply).
>
> OK, this idea is growing on me.
>
> What do people think of updating rfc5666bis to restrict
> RDMA_ERROR to be sent only by responders? This would be
> for RPC-over-RDMA V1 only, of course.
>
> The reason to do this would be to eliminate the ambiguity
> of the meaning of the XID and credit value, due to the
> absence of an RPC message payload with a direction field
> in it.
>
> I'm not aware of any current requester implementation
> that can send an RDMA_ERROR message from its reply
> handler.
>
>
> > So the only instance where a server might receive an
> > RDMA_ERROR message is when it has sent a backward
> > request that the client did not like.
> >
> > Thus: context indicates what direction that RDMA_ERROR
> > message is going.
> >
> >
> > --
> > Chuck Lever
> >
> >
> >
> > _______________________________________________
> > 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
>