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 <Spencer.Shepler <at> sun.com>
Brian Pawlowski <beepy <at> 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 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
RSS Feed