Subject: [nfsv4] The case for mandatory v4.1 sessions

From: "Talpey, Thomas" <[email-masked]>
Date: Thu, 30 Mar 2006 16:39:52 -0500

At the WG meeting last week, I took the AI to take a stab at
the statement for making Sessions a mandatory requirement
for NFSv4.1 in all cases. Here goes.

It's a multipart argument.

- All the interesting new features of NFSv4.1 depend on having a session
  in place between client and server. pNFS requires operation sequencing
  and context on its exchanges, and directory delegations require context.
  Without this information provided by the session, these will require much
  more extensive changes to the NFSv4 operations.

  Sessions themselves add several compelling features, including reliable
  exactly-once semantics, operation across firewalls, trunking and
  multipathing, and recovery.

- The protocol is simpler with sessions than without. In addition to a
  proliferation of new operations to support pNFS and directory delegation,
  there would be many different (and imperfect) ways to manage these
  exchanges. "If a session is in place, <x>, else <y>". Such duplication
  adds complexity and impacts interoperability, in addition to exploding
  the testing matrix. It can also dissipate the focus of implementations.

  Sessions can reduce the number of requests on the wire, some of them
  from critical paths (such as OPEN_CONFIRM). This can enhance the
  performance between sessions-enabled clients and servers.

- The reliability semantics of sessions are compelling. Servers will be able
  (but are not required) to implement perfectly correct duplicate request
  caches in a resource efficient way. This will improve the correctness of
  the protocol, and its acceptance. It enables more efficient server processing.
  It allows clients to employ multi-wire trunking, failover and recovery without
  impacting these semantics.

- The implementation is non-onerous. For Linux 2.6, the core sessions
  sequenceid/slotid/DRC implementation is ~1500 lines of new client code,
  ~1000 of new server code.

Tom.

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