Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-03 (part one of three)

[Chuck Lever <[e-mail]>]

Hi Dave-

Thanks for the review. Responses to your General Comments are below.


> On Dec 19, 2016, at 5:56 PM, David Noveck <[e-mail]> wrote:
> 
> Review Structure
> 
> This is the first part of a multi-part review.  It is split into multiple emails to avoid running into mailing list size limits.
> 
> This part consists of:
> 	• General Comments
> 	• Comments by Section (through Section 3)
> Later emails will contain the rest of the per-section comments.
> 
> General Comments
> 
> Overall Evaluation
> 
> I think this document is fairly far along in meeting the original requirements, to replace RPC5667 and supplement it with a reasonable treatment of NFSv4, not really dealt with in RFC5667.
> 
> However, in a number of respects, the current text has issues that need to be addressed before going forward and I've made some suggestions as to how those issues could be addressed.  These issues are:
> 	• Adaptation to the possiblility of multiple RPC_over-RDMA versions, whether that is done as outlined in draft-cel-nfsv4-rpcrdma-version-two or not.  This issue is discussed in Handling of RPC-over-RDMA Transport Versions.
> 	• The need to address some fundamental issues regarding the ability to bound reply size.  I have suggested a way to do that in the proposed new section 2.x.  Difficulties in Reply Size Estimation

I predict some resistance to section titles in a specification that include
the word "Difficulties".

The point has been made, however, that without proper Reply Size Estimation,
successful interoperation is at risk. This is why we now call out Reply Size
Estimation in RFC 5666bis as a necessary part of an Upper Layer Binding.

I agree that there are plenty of details that need to be sorted here. Your
comments in this area are most helpful, and I plan to integrate many of them
into this document. I hope we can resolve most RSE issues so that the use of
the word "Difficulties" will be rare or altogether unnecessary.


> Handling of RPC-over-RDMA Transport Versions
> 
> Even though the I-D for Version Two has not yet been adopted as a working group document and there may be some dispute as to the proper direction such a new version might take, it is now clear that further development of RPC-over-RDMA is likely to take place.  In light of the fact that we can no longer assume Version One will be the only version, we have a number of choices:
> 	• Make the current document the ULB for NFS applying to RDMA-over-RDMA Version One only or to Version One plus a very small Version Two.  Note that later changes to an extensible transport version might make a lot of the current statements about how DDP will be done, inappropriate. For example, a version two based on draft-cel-nfsv4-rpcrdma-version-two might not require much change but the later addition of features for message continuation and  send-based DDP, as set out in draft-noveck-nfsv4-rpcrma-rtrext would essentially force a rewriting of the document, even if those feature were OPTIONAL.
> 	• Cut back the scope of the current to eliminate most of the explanatory material tied to Version One of the transport and leave it oly containg the mateial that rfc5666bis requires for ULBs.
> 	• Restructure the document to distinguish material required by rfc566bis and applicable to all transport versions from explanatory/illustrative  material tied to Version One.
> In my revision suggestions, I have adopted the last of these approaches.

I prefer to keep the NFS ULB document as agnostic to transport protocol
version as possible. That would increase its useful lifespan, rather 
than requiring a fresh ULB later to handle subsequent versions of
RPC-over-RDMA.

I assume you object to the use of terminology that mentions a particular
RDMA mechanism (eg. RDMA Read, or Read chunk), since that is incompatible
with potential extensions to RPC-over-RDMA which might use some other
mechanism (eg. structured Send buffers).

On considering replacing that language with abstract terminology such as
"DDP-eligible", that could make the document more difficult for implementers
to interpret. It would certainly bear little resemblance to the original RFC
5667.

Likely all of Section 2 would need to be rewritten or removed. I believe
removal of this section would be a disservice to implementers.

IMO it's treading a fine line to consider non-RDMA Direct Data Placement
mechanisms in a transport protocol called "RPC-over-RDMA".

Be that as it may, I will see what can be done to address your concerns in
this document. Because I'm not taking "the last of these approaches" (see
above), at least for now, I will probably not merge many of your proposed
changes in this area, but will use the body of your remarks as a guide to
rework the text to be agnostic to data placement mechanism.


--
Chuck Lever