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

[David Noveck <[e-mail]>]

A week ago I wrote:
> 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.

It's now been at least two weeks since last call was supposed to end for
the Version One RDMA documents
and a week since Chuck posted any necessary updates.  I'm not sure why the
documents are still listed as in
WGLC, but I wanted to make it clear that my comments above should not be
holding these up.

Those comments refer to a problem that is inherent in Version One  and
cannot be fixed within the constraints
of a Version One no-XDR-change update.  Since the Working group has decided
to do a Version One no-XDR-change
update, the three existing RDMA documents should now go forward.  I don;t
believe there is any disagreement on
that point.

On Fri, May 27, 2016 at 1:33 PM, David Noveck <[e-mail]> wrote:

> > 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
>>
>>
>>
>>
>