NFSv4 WG Meeting minutes 
IETF59 Seoul 
March 4, 2004, 1300-1500 

The agenda was: 

Network File System Version 4 (nfsv4) 
------------------------------------- 
  
Chair(s): 
  
    Spencer Shepler <Spencer.Shepler@sun.com> 
    Brian Pawlowski <beepy@netapp.com> 

AGENDA:  Thursday, March 4, 2004: 13:00pm - 15:00 (2 hours) 
  
    Welcome and Introduction            (Talpey)         1 min 
    Agenda bash 
        - Blue Sheets 
        - NOTE WELL 
  
    Connectathon results                (Shepler by proxy) 15 min 
    NFS V4 interoperability testing 
  
    Review and discussion of NFS/RDMA 
                                                (Talpey)         30 min 
    NFS RDMA Problem Statement 
    NFS RDMA Requirements 

    Potential Minor Version Work - 20 mins 
         Review existing items 
         Informational items: 
            Parallel NFS (pNFS) position statement - (Talpey) 
  
    Open discussion                     (Talpey)          30 min 
  
    Wrapup                              (Talpey)          1 m 
  
  
Brian was unable to attend at the last minute, so Tom Talpey sat in as 
Chair Pro Tem. :-) 

Agenda bashed 
Blue sheeted 
Noted well 

- Connectathon Results (Shepler by proxy) 

  There were seven NFSv4 implementations at the recent 
Connectathon, of which seven were servers and four were clients. The most 
ever! 

  NFSv4 testing went smoothly, with no protocol or specification issues 
found. All implementations were testing Kerberos, and some testing of 
"advanced" features, such as ACLs and delegations was done. There was 
interest in continuing the NFSv4 Bake-a-thons. 

  Numerous bugs were found and fixed, all basic Cthon tests were 
completed by all. ACLs were rough (owing to the recent mapping changes) but 
broad agreement on the needed fixes was had. 
Replication/migration and fs_locations were missing in action, however. 

  NFS/RDMA prototyping efforts were also tested, based on NFSv3 
implementations. Sun, CITI and NetApp tested a Linux client, Sun client and 
server, and NetApp server. There were discussions related to including the 
NFSv4 Session extensions in a minor revision. 

  Possible items for a v4 minor release: 
    + Channel Conjunction Mechanism (CCM, 
draft-ietf-nfsv4-ccm-02.txt) 
    + Sessions 
(draft-talpey-nfsv4-rdma-sess-01.txt) 
    + Directory delegation 
(draft-khan-nfsv4-directory-delegation-00.txt) 
    + Clarifications/bugfixes 
    + More tbd... 

  Questions were asked: 

    Q: which Linux implementations were testing v4? 
    A: Primarily Linux 2.6. 

    Q: Was any security other than Kerberos being tested? 
    A: The focus was on the mandatory NFSv4 security - Kerberos. SPKM3 
testing was also performed by the CITI Linux implementations. 

    Q: What are the goals of v4 fs_locations? 
    A: Covered in the RFC and drafts. 

    Q: Is there interest in employing IPSec? 
    A: Yes, absolutely, refer to the CCM draft. 

    Q: How does NFS detect that IPSec is in use? 
    A: Local interface issue. 

- NFS/RDMA Document Review (Talpey): 

  The "NFS RDMA Problem Statement" document was presented. Updated in 
February,   
draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt. The document 
demonstrates that RDMA can reduce the overhead encountered by NFS 
implementations, by eliminating data copies and offloading network 
processing. Overhead in NFS stems from the message formats and the 
presence of XDR. Page flipping, and protocol offload solutions are 
quantifiably less effective than RDMA. Many references are provided. 

  Questions: 

    Q: Is the RDMA Advantage primarily from copy avoidance or offload? 
    A: Clearly both, but the largest benefit comes from copy 
avoidance. This is discussed in the referenced papers. 

    Q: What overhead is due to using TCP versus UDP? 
    A: TCP and UDP are now practically identical in performance and most use 
TCP now. In fact, v4 requires a congestion-controlled transport - TCP. 

    Q: What overhead difference is seen between V3 and V4? 
    A: Performance between v3 and v4 is nearly identical as well, but v4 
affords additional performance from delegations which may permit it to 
outperform V3. 

    Q: Can't TOE perform certain copy avoidance? 
    A: Yes, but very limited, and not on receive. 

  The "NFS RDMA Requirements" document 
(draft-callaghan-nfsrdmareq-00.txt) was next. This document lays out the 
basic requirements made by NFS/RDMA on any RDMA transport, as input to the 
RDDP group in particular. The requirements are compatible with the 
current RDDP, with security integrity and privacy listed as 
desirable. The relative functions of an RDMA layer versus NFS and RPC are 
explored, and some guidelines for efficiency. 

- RDDP WG questions for NFSv4 WG: 

  This discussion led directly to an item from the previous day's RDDP 
Working group meeting. Does the NFS/RDMA effort wish RDDP to make 
support of IPSec "mandatory to implement, optional to use"? The RDDP 
working group seeks the NFS group's input on this, and also whether SSL or 
other TLS support is desired, and whether there may be interactions 
between RPCSEC_GSS and RDDP. 

  An opinion was stated in the room - RDDP IPSec, and its use by 
NFS/RDMA, should be mandatory to implement and optional to use. The 
reasons were as follows: 
    1) These are new protocols - they should come out of the gate as 
secure. NFS should not leave IPSec-secured storage to "the block guys" 
(iSCSI :), and should be just as secure in all modes. (IPSec is 
mandatory for iSCSI). 
    2) Things move through IETF much better when they are mandatory, 
especially security. Ensuring that vendors must provide it, and letting the 
user decide to use it, is better for the industry. 
    3) Security support in hardware avoids data touches in software. So an 
IPSec enabled NFS/RDMA can achieve higher performance. 

- Questions were asked on issues which are open on the mailing list: 

  Q: Global namespace? Is there a draft? 
  A: No, but there has been significant discussion. At 
Connectathon, there was agreement to implement an nfsv4.0 version, and thus 
learn what else may need to be done in future nfsv4.x. 
  Q: Is the current fs_locations good enough? 
  A: Some think yes, some no. 
  Q: Is there an effort to define the "general form of a namespace"? 
  A: Not active. (?) 
  Q: What is the status of the replication/migration effort? 
  A: At Connectathon, Rob Thurlow indicated that an update to the draft was 
in progress. 

- Parallel NFS (Talpey) 

  An informational presentation on a possible future NFSv4 chartered 
effort followed - "Parallel NFS". (See presentation 
pNFS-intro-ietf59.pdf) This is an accompaniment to 
draft-gibson-pnfs-problem-statement-00.txt. 

  Parallel NFS is a product of a workshop held at CITI last December. The 
effort is to explore NFSv4 extensions to meet scalability needs, 
including parallelizing NFS requests, and exporting block and object 
"layouts" to enable direct client access to storage. 

  The presentation states that the problem is that NFS clients 
experience limited bandwidth due to the NFS protocol linkage of files to 
servers. The goal is to distribute file and objects across multiple 
servers in order to eliminate this bottleneck. 

  The presentation goes on to argue that the subject is highly relevant to 
the IETF because it expands NFS's role, standardizes what is today 
proprietary, and links NFS to other IETF efforts such as iSCSI. 



  Questions: 
  Q: Parallel NFS enables direct access to data, is there an implicit 
object specification? 
  A: This is the subject of future discussion, but the goal would be to 
provide a standard and extensible specification for numerous types. 

  Q: How would the extension include all of "striped" NFS, blocks and 
objects? 
  A: The intent of group is to provide "layouts" which are 
transport-independent. 

  Q: How can we achieve interoperability with all these multiple 
layouts? 
  A: The format of the maps would be defined by this proposal, and the 
client would participate in the decision to use them. 

  Q: Still an interop concern, because of the many possible formats. 
  A: Yes, an important issue for the discussion going forward. 



Ends 1405