Subject: [nfsv4] AD review: draft-ietf-nfsv4-nfs-rdma-problem-statement-06

From: Lars Eggert <[email-masked]>
Date: Mon, 28 May 2007 16:39:07 +0300

I'm trying to do the AD review phase early (i.e., in parallel WG last  
call rather than afterwards), and for this document it has actually  
worked.

Summary: Generally good to go. Needs minor editorial wordsmithing.

Detailed comments:

INTRODUCTION, paragraph 13:
 >      This draft addresses applying Remote Direct Memory Access to the
 >      NFS protocols.  NFS implementations historically incur  
significant
 >      overhead due to data copies on end-host systems, as well as  
other
 >      sources.  The potential benefits of RDMA to these  
implementations

   "as well as other sources" - can't parse. Does this refer to other
   sources of overheads, or other places where data copies are done?

Section 1., paragraph 7:
 >      The External Data Representation [RFC4506] employed beneath  
NFS and
 >      RPC [RFC1831] can add more data copies, exacerbating the  
problem.

   Given that 1831bis will obsolete RFC1813 very soon, should we cite
   1831bis here and elsewhere in this document?

Section 1., paragraph 9:
 >      In recent years, an effort to standardize a set of protocols for
 >      Remote Direct Memory Access, RDMA, over the standard Internet
 >      Protocol Suite has been chartered [RDDP].  Several drafts  
have been
 >      proposed and are being considered for Standards Track.

   RDDP will be published by the time this draft is done - rephrase
   paragraph.

Section 2., paragraph 3:
 >      Furthermore, NFS will soon be challenged by emerging high-speed
 >      network fabrics such as 10 Gbits/s Ethernet.  Performing even  
raw
 >      network I/O such as TCP is an issue at such speeds with today's
 >      hardware.  The problem is fundamental in nature and has led the
 >      IETF to explore RDMA [RFC4297].

   10 Gb/s Ethernet is here - rephrase paragraph.

Section 7., paragraph 1:
 >      Security Considerations are not covered by this document.   
Please
 >      refer to the appropriate protocol documents for any security
 >      issues.

   Please briefly summarize which security issues are discussed in which
   "appropriate protocol document" and include a reference.

Section 8., paragraph 1:
 >      IANA Considerations are not covered by this document.  Please  
refer
 >      to the appropriate protocol documents for any IANA issues.

   Rephrase as: "This document has no IANA considerations." (Clearer for
   IANA.)

The rest are all nits (typos, etc.)

Section 1., paragraph 2:
 >      Historically, remote file access has proved to be a convenient,

   Nit: s/proved/proven/

Section 1., paragraph 11:
 >      well, e.g. TCP, further reducing CPU overhead due to NAS

   Nit: s/e.g./e.g.,/ (also elsewhere)

Section 3., paragraph 7:
 >      unmarshalling process, because the destination adddress is not

   Nit: s/adddress/address/

Section 4., paragraph 7:
 >      A common question is whether increase in CPU processing power

   Nit: s/whether increase/whether an increase/

Section 4., paragraph 10:
 >      and are not scaleable to multi-processor architectures.  Correct

   Nit: s/scaleable/scalable/

Section 10., paragraph 1:
 >      [RFC3530]
 >           S. Shepler, et. al., "NFS Version 4 Protocol", Standards  
Track

   Nit: s/et./et/

Section 11., paragraph 11:
 >           Monterey, CA, June 9-14, 2002.

   Nit: s/Monterey,/Monterrey,/

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Talpey, Thomas" <[email-masked]>
Date: Mon, 28 May 2007 10:12:18 -0400

Thanks! We'll incorporate these after collecting any others.
Some small comments below.

>   sources of overheads, or other places where data copies are done?

Sources of overheads. Will clarify.

>   1831bis here and elsewhere in this document?

I considered changing that but decided the RFC Editor would be the
best arbiter. I did fix the (now official) XDR one, in the same spot btw.
But you're right, I'll go ahead and change 1813 too since it's in progress.
 
>   RDDP will be published by the time this draft is done - rephrase

I'll change and add a flagged reference for the RFC editor.

>   10 Gb/s Ethernet is here - rephrase paragraph.

Yes, but it's still "emerging" :-) We'll change it of course.

>   Nit: s/Monterey,/Monterrey,/

Actually the single "r" is correct for CA, the Monterrey one is in Mexico.

Tom.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 28 May 2007 17:51:33 +0300

> But you're right, I'll go ahead and change 1813 too since it's in  

The RFC Editor won't make any changes here unless requested. If you  
leave the reference to 1813 in place, that's what will be in there.  
If you normatively refer to 1813bis instead, the RFC Editor will hold  
this document until it published 1813bis and will then replace the  
reference to the 1813bis draft with its RFC number.

> Actually the single "r" is correct for CA, the Monterrey one is in  

Heh. Most things flagged as "nits" are found by my review script, and  
that doesn't know about countries :-)

Lars