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

[Chuck Lever <[e-mail]>]

> 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