Re: [nfsv4] AD Evaluation for draft-ietf-nfsv4-rpcrdma-bidirection-05

[Chuck Lever <[e-mail]>]

Again, thanks for your review! Responses below.


> On Jan 10, 2017, at 4:32 PM, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> Hi, Spencer (S), 
> 
> I think this catches me up on nfsv4 AD Evaluations ...
> 
> Again, this draft was pretty clear to me, but I did have some questions about wording, that I'd like people to look at, before requesting IETF Last Call. 
> 
> Spencer (S), could you let me know when this draft is good to go?
> 
> Thanks!
> 
> Spencer (D)
> 
> --- AD Evaluation
> 
> Could you spell out "Parallel NFS" on first use of pNFS? Or whatever pNFS stands for :-)

Will do.


> Probably just for my benefit, but since you mention NAT routers in this text,
> 
>    To facilitate operation through NAT routers, all NFSv4.1 transport
>    connections are initiated by NFSv4.1 clients.  Therefore NFSv4.1
>    servers send callbacks to clients in the backward direction on
>    connections established by NFSv4.1 clients.
>    
> is it obvious which end has responsibility for NAT binding keep-alives? I'm guessing that's a client responsibility, but that's just a guess.

I don't understand what NAT binding keep-alive means, exactly, but
based on a naive assumption, I think the client is responsible here.
If anyone knows of a cite-able summary of the NFSv4.1 backchannel
redesign goals, I can reference it here.


> In Sections 4.3.1 and 4.3.2, I THINK you're saying that clients and servers both need to pre-post more receive buffers to accommodate bidirectional operation, but that's more clear in 4.3.1,
> 
>    To receive incoming backward direction Calls, an RPC-over-RDMA client
>    endpoint must pre-post enough additional receive buffers to match its
>    advertised backward direction credit value.  Each outstanding forward
>    direction RPC requires an additional receive buffer above this
>    minimum.
>    
> than the corresponding text in 4.3.2,
> 
>    To receive incoming backward direction replies, an RPC-over-RDMA
>    server endpoint must pre-post a receive buffer for each backward
>    direction Call it sends.
>    
> because "additional" appears twice in the text on 4.3.1, but doesn't appear at all in 4.3.2. If this is as symmetrical as I'm thinking it is, perhaps it's clearer to use similar wording in both places.

I will use similar wording in both places.


> In this text, 
> 
>    When message direction is not fully determined by context (e.g.,
>    suggested by the definition of the RPC-over-RDMA version that is in
>    use) or by an accompanying RPC message payload with a call direction
>    field, it is not possible for the receiver to tell with certainty
>    whether the header credit value is a request or grant.  In such
>    cases, the receiver MUST NOT use the header's credit value.
>    
> does RDMA work at all, if the credit value can't be used?

What this means is the receiver MUST NOT update its credit accounting
based on the information in this header. These foggy situations should
be exceptionally rare.

"MUST ignore" might be more appropriate.


--
Chuck Lever