[nfsv4] DRAFT NFSv4 Working Group IETF-59 minutes

["Talpey, Thomas" <[e-mail]>]

The NFSv4 Working Gorup meeting was held today at
IETF-59 here in Seoul. Please read and comment on the
following minutes, before inclusion in the proceedings.

Thanks,
Tom.

-----

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

The agenda was:

Network File System Version 4 (nfsv4) 
------------------------------------- 
  
Chair(s): 
 
    Spencer Shepler <[e-mail]> 
    Brian Pawlowski <[e-mail]> 

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 then Kerberos being tested?
    A: The focus was on the mandatory NFSv4 security - Kerberos.

    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. Not aware of any draft
  currently in progress.
  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