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

[David Noveck <[e-mail]>]

> But true enough, there may be others.

There are others but I'm coming to the conclusion that it would be too
disruptive to try to address them in Version One :-(

Fortunately, we don't have to since these are very unusual situations :-)

For example, "RDMA_ERROR is responder-to-requester only" does not admit an
ambiguity in a one-direction-only context.

The problem is that, in a multi-direction context, a given implementation
only knows whether it is a client or
a server.  It only knows if it is a requester or a responder based on the
message it is processing at any given
instant and if it can't figure that out, it is unsure whether it is a
requester or responder and may be neither at
particular times.

Sigh!


On Fri, May 27, 2016 at 10:01 AM, Chuck Lever <[e-mail]>
wrote:

>
> > On May 27, 2016, at 8:24 AM, David Noveck <[e-mail]> wrote:
> >
> > I wrote:
> > > but I have a problem with writing the spec as if
> > > such situations don't exist.
> >
> > I've been thinking more about this.  I think the problem lies in what I
> mean by
> > "the spec".  If that means "rfc566bis", then such situations cannot
> exist.
> > rfc566bis seems to only deal with forward direction operation.  In such
> an environment,
> > if you are a client and you receive a message, it has to be a reply.
> Similarly, if you are
> > server and you receive a message, it has to be a request.  So there is
> no occasion for the
> > kind of ambiguity I'm concerned about.
> >
> > On the other hand, if "the spec" means "the specification of
> RPC-over-RDMA Version One",
> > in which multiple directions of operation can be supported, the
> ambiguity is unavoidable. If
> > you (client or server) receive a message you do not know a priori,
> whether it is a request or
> > a reply and there are situations in which the receiver cannot determine,
> given a malformed
> > message, whether it has received a malformed request or reply.
>
> I left the existing language in rpcrdma-bidirection.
> So Section 4.1 still has:
>
> >    When message direction is not fully determined by context or by an
> >    accompanying RPC message with a call direction field, it is not
> >    possible to tell whether the header credit value is a request or
> >    grant, or whether the value applies to the forward direction or
> >    backward direction.  In such cases, the receiver MUST NOT use the
> >    header’s credit value.
>
>
> Adding the "RDMA_ERROR is responder-to-requester only"
> to rfc5666bis, plus this from Section 5.1:
>
> >    The rdma_vers field MUST contain the same value in backward and
> >    forward direction Call messages on the same connection.
>
>
> And this from Section 6:
>
> >    Therefore, an Upper Layer Protocol consumer MUST NOT perform backward
> >    direction ONC RPC operations unless the peer consumer has indicated
> >    it is prepared to handle them.
>
>
> All serve to close the largest windows of ambiguity we
> know about. But true enough, there may be others.
>
>
> --
> Chuck Lever
>
>
>
>