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

[Karen <[e-mail]>]

Hi Chuck,

Here is some feedback on draft-ietf-nfsv4-rpcrdma-bidirection-03

Karen


Abstract section:

The use of the word "recent" seems relative to time.  5 years later, 
recent will no longer be recent.  Not sure how much of a big deal this 
is, just seems maybe instead of putting "recent minor versions of 
NFSv4", a more precise explanation would be "With the introduction of 
NFSv4.0".


2.1

/"This traditional form of ONC RPC message passing is referred to as 
operation in the "forward direction"."/

"as operation in the forward direction" seems awkward.  "is referred to 
as the "forward direction"." seems a bit more concise and clearer.

2.2

Same as in section 2.2 in /"This form of message passin is referred to 
as operation in the "backward direction."/

Also again the use of the word recently, as in "Not until recently", 
seems that "Not until NFSV4.0" would be clearer.

3.1

/"An NFSv4 "delegation" is simply a promise made by a server that it 
will notify a client before another agent is allowed access to a file"/

another agent? seems "a different client" would be clearer.

3.2

/"Without a backward direction RPC-over-RDMA capability, an NFSv4.1 
client must additionally connect using a transport with backward 
direction capability to use as a backchannel."/

I understand the point, and agree, but the sentence seems mumbled.  
Maybe its confusing to me because of the use of the word backward 
direction.  Maybe backward direction needs to be defined as a connection 
that is initiated by a requestor, but also used to accept requests from 
the respondor, in which the requestor then reponds?  Not sure if that 
wording is any clearer, but the idea that the requests are sent from the 
side that did not create the connection?


4

"/For an RDMA Send operation to work, the receiving peer must have 
posted an RDMA Receive Work Request (WR) to provide a receive buffer in 
which to land the incoming message./

why is the posted receive buffer being called a posted receive work 
request?  Seems this would be clearer

"For an RDMA Send operation to work, the receiving peer must have posted 
an RDMA receive buffer as the location in which the RDMA send request 
will land."


And similarly


/"If a receiver hasn't posted enough Receive WRs to land incoming Send 
operations..."/

If a receiver hasn't posted enough receive buffers to accept incoming 
send requests"

(Why is Receive capitalized?)


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.

4.2

/"If a sender transmits a message for a receiver which has no prepared 
receive buffer"/

the word "posted" not "prepared" was used earlier, to be consisted 
"posted" would read more clearly than "prepared"

4.2.2

/"A forward direction RPC-over-RDMA service endpoint"/

//

did you mean "server" instead of "service"?

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

What prevents a buggy, or hacking client from sending more requests that 
forward credits and preventing a reply in the backward direction from 
arriving?  Could a buggy or hacky client cause a denial of service by 
sending more than credit number of requests?  Guess that could happen in 
the standard single direction and would result in the connection 
closing.  Maybe not an issue?

5.1

last sentence,/"and the header's msg_type field MUST conatin the value 
CALL",
/

for more clarification "and the RPC header's msg_type field", this is a 
nit...

5.4

/"If an ONC RPC client has no work to do, it may be some time before it 
re-establishes a transport connection. Backward direction Requesters 
must be prepared to wait indefinitely for a connection to be established 
before a pending backward direction ONC RPC Call can be retransmitted."/

I don't believe there are currently an non-idempotent backchannel 
operations, but if there ever were to be, seems that the client should 
detect if it has any drc replies and re-create the bi-directional, or 
even one way backchannel connection, right after it detects the 
connection is  gone.


Not addressed, and obvious to the implementer, but should it be 
mentioned that send buffers in the backward direction MUST be the same 
size as the posted receive buffers on the receiving side? That is the 
backward connection must use the same send/recv buffer sizes and this 
can not be negotiated?