NFSv4 Working Group Meetings @ 42nd IETF Chicago Reported by Brent Callaghan with contributions from Mike Eisler and Brian Pawlowski. Morning Session The morning session was attended by about 50 people. It was organized as a series of presentations intended to present the state of the working group and its drafts. Brent Callaghan lead off with an overview of the agenda for morning and afternoon sessions, a brief history of the NFS protocol and its versions, an account of events leading to the formation of the working group, and the draft working group charter and milestones. Brian Pawlowski responded to a question as to whether NFS version 4 server would support previous versions. NFS servers are typically compatible with all previous versions. Brent mentioned that the milestones assumed availability of prototype implementations early next year, though some of these early prototypes may implement and test subsets of the protocol. Spencer Shepler presented an outline of the Requirements Document, which is designed to focus attention on the rationale for the working group and answer such questions as: What do we need to fix in NFS version 3 ? What good features of NFS should be preserved ? Continued use of the ONC RPC protocol seems to make sense given that it is already on standards track. What new problems does the new protocol need to address ? What are the cost/benefit tradeoffs ? The current draft needs to include more comparisons with existing distributed filesystems. Spencer then moved on to present an overview of the Strawman protocol document. This is a rough protocol specification intended to provide a nexus for proposals relating to specific protocol features. The strawman protocol integrates the mount and file locking protocols into a single NFS protocol. File names are encoded UTF-8 strings and name files within a single-root namespace on the server. Security utilizes the RPCSEC_GSS framework (now a Proposed Standard) into which public key schemes, like SPKM and private key schemes like Kerberos version 5, can be integrated. File attributes are an extensible set, individually gettable and settable. NFS operations can be aggregated into compound requests to provide more implementation flexibility and address network latency. Integrated file locking operations utilize leases to avoid the need for server callbacks or status monitoring. The strawman leaves many open issues in the implementation of locking, minor versioning, required attributes, Access Control Lists and security mechanisms. The future evolution of the strawman will be guided by the final requirements document and the charter that derives from it. Uresh Vahalia gave a short presentation outlining some issues and proposals for NFS v4: NFS version 4 must perform well enough to provide very high bandwidth to servers with many terabytes of data. While TCP is good for the Internet, UDP is still significantly faster then TCP for NFS on LANs. We need to think about providing client advisories to the server for file space reservation, caching policy, and per-file access advisories. A file copy operation could be executed more efficiently on the server. NFS version 4 also needs to work well with other file access protocols. The morning session ended with a brief introduction by Brian Pawlowski to topics that we should keep in mind for the afternoon session, i.e. what are the deficiencies in the current protocol ? What is critical for NFS v4 ? Will it support Windows ? And finally, a reality check: can it be implemented ? Afternoon Session The afternoon session promoted an interactive discussion of problems with NFS and possible solutions for version 4. Since the group was in a much larger room than needed (40 or so in a room for 200) we exchanged rooms with the MPLS WG. Brian Pawlowski then moderated the discourse over a series of agenda items: Security: Which security flavors should be implemented ? There was some disagreement as to whether schemes should be mandatory and which schemes should they be. There seemed to be some reluctance to require only strong security to be negotiated. Negotiation of security negotiated at the connection level (e.g. TLS) was also raised. Edwards Reed of Novell provided a good reference to draft- newman-auth-mandatory-00.txt (April 98) "The Mandatory-to-Implement Authentication Problem" which discusses this issue. There was also some questions on the use of strings to identify users and groups and the mapping of these strings to local representations. The question of support for Access Control Lists was raised. There is a problem determining which ACL model to support: POSIX, Windows NT, or DCE/DFS ? Latency and Bandwidth: Where access to server data is limited by bandwidth and latency, clients can benefit from aggressive caching. There was agreement that NFS version 4 should support this though no specific proposals as to what support was needed within the protocol. A feature that allows the server to notify clients of changes to cached data would assist cache consistency though this would be difficult to support on an Internet scale. Brian Pawlowski mentioned that the SMB/CIFS protocol already uses "oplocks" to support cache consistency albeit with a requirement for much client state to be held on the server. The use of a streaming protocol, like SGI's BDS, to better utilize bandwidth for large data transfers was mentioned, though a close approximation to streaming can be realized through very large READ and WRITE requests already possible with NFS version 3. Filesystem Model: NFS assumes a single-rooted, hierarchically organized tree of directories with files as leaf nodes. Files are assumed to be an uninterpreted sequence of bytes. There was a question as to whether NFS version 4 should allow this model to be extended to handle multi-stream files as supported by NTFS and MacOS (data & resource forks). NTFS data streams can be created, deleted, are renameable and lockable. One possibility is to allow a multi-stream file to function both as a directory and as a file. Support for case-insensitive lookups and wildcard matching were also mentioned as requirements for PC support. One objection raised was the complexity this introduces in reserving wildcard characters in filenames and specifying case in a Unicode context. File Attributes: If the protocol is to allow file attributes to be set and read individually, what are the expectations of a client or server as to which attributes will be supported and which will not ? What should the server do if the client sets and attribute it cannot support ? The specification should state a clear policy on the issue of attribute support. The use of "extended" attributes was mentioned: values named with arbitrary strings. One way to support these may be through the concept of named data streams within a file context. Naming: There was some support voiced for a proposal to provide a global NFS namespace through an LDAP schema, perhaps described in a separate document. There was some disagreement as to whether the use of Unicode filenames in NFS v4 required the separate specification of a codepage to be used. There seemed to be general agreement that the use of on-the-wire UTF-8 encoding precluded the need for codepage specification. Locking: David Robinson outlined an alternative locking proposal to that described in the strawman. His proposal allows clients the option of having mandatory or advisory locking and uses different mechanisms for extension of leases and lock recovery. Ira Slutskaia pointed out a flaw in the proposal that prevented an I/O request from straddling two independently locked regions in a file. There was some disagreement as to whether the lock protocol should allow a lock to be lost or denied to a client. There are locking APIs that assume locks are held indefinitely and have no mechanism for notifying an application that a lock is lost. Solaris has a SIGLOST signal, but it is not widely supported on other Unix implementations. Mike Eisler pointed out though that existing NLM protocol does cause one to lose locks. DOS File Sharing: DOS applications exercise a form of whole-file locking when a file is opened called a "share" which specifies both and access mode (read, write, read-write) and a deny mode (none, read, write, all). These semantics are currently implemented by the NLM protocol but only in an advisory form. The strawman locking protocol cannot be used to reproduce the precise share semantics either. Although there is consensus that PC applications should be better supported by NFS version 4, there is some debate as to what degree the share semantics should be supported, whether non- DOS applications should be required to support share semantics, and whether the share semantics should be supported as a type of lock, or as a new form of file or directory lookup. Testing: There was a brief discussion on the approach to testing of v4 implementations. Implementors should make their servers available on the Internet to facilitate client and server testing. Clients and servers should also be tested through firewalls. Brian Pawlowski concluded the session with a request that the disparate locking proposals be resolved along with the a coherent proposal for support of DOS shares.