Subject: RE: Proposed charter addition for NFS Version 4 Working Group

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 11 Dec 2002 15:24:59 -0800

R. J. Atkinson wrote:
> We've shipped 10 GigE, so I'm not claiming that it won't get deployed.
> I am questioning whether it is necessary to change the NFS protocol
> to make NFS work well over 10 GigE.  At least one other person today
> indicated that he does not think it is necessary to change the NFS
> protocol to make NFS work well over 10 GigE (he might have meant that
> changes could be confined to RPC rather than NFS itself, but his
> precise meaning was not crystal clear to me).

Well Rob can clarify, but he said:
> If you don't find that existing NFS systems fail to be able to
> take advantage of 10Gb and higher links, that would be contrary
> to what we're seeing.  It seems impossible to do significantly
> better without smarter NICs and at least some over-the-wire
> information; I'm convinced from reading the RDDP materials.
> That will likely not impact the NFS protocol at all, and should
> have a relatively small and well-understood effect on NFS
> implementations.  So I actually don't understand why this has
> triggered your complexity alarm.

So when he speaks of "at least some over-the-wire changes", it
sounds like a protocol change somewhere in the protocol stack is
occurring.  If everything was the same, then the same bits would
be going over the wire.  Since he mentions RDDP, then I'm assuming
that at least of the data that is currently going over TCP will go 
over RDDP and that brings other protocol changes in its train.
I think it is possible to confine changes to layers below NFS,
so that at least formally, there is not protocol change to NFS.

But from an interoperability point of view, the protocol is changing 
and both sides, including the NFS-v4 client and server have to play
by the same rules, so this is effectively a protocol change.  There may
be advantages to doing the work at one level of the protocol stack
or the other and I assume the working group will deal with that issue.

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 12 Dec 2002 12:49:06 -0800

Mike Eisler:
> Perhaps the charter should make it clear that any  extensions to NFSv4 to
> use direct data placement should not be required to use other unrelated
> extensions. I'm certainly approaching v4.1 with that constraint.

I certainly agree with that constraint.  As far as putting it in the charter,
I'd like to keep the charter within some reasonable bound.  Adding this
constraint would not be a big deal, but if everybody wanted to add his
favorite design constraint (no matter how reasonable) to the charter,
it would get unmanageable.

Let's get the charter out of the way quickly and then we can work on the
design.  In doing so, we should spend some time early on, on just those
sorts of design constraints.  I think it will help make the rest of the
design process go more smoothly.

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 3:32 PM
To: RJ Atkinson
Cc: Noveck, Dave; nfsv4-wg
Subject: Re: Proposed charter addition for NFS Version 4 Working Group

RJ Atkinson wrote:

 > As a user and administrator, NFSv4 has not bought me *anything*
 > in the way of simplicity.  I've already got to deal with both
 > NTFS and NFSv3.  NFSv4 increases my complexity with no substantive
 > benefits to me as a user or administrator.  This isn't the first
 > time I've said this, and I think I might be the only user or
 > administrator
 > in this WG, but the WG is pretty consistent in picking complexity
 > over simplicity.  Simplicity and ships-in-the-night filesystems
 > would make my life a lot better.

Removing the NLM and Status Monitor protocols and
including equivalent (actually superior) functionality in the
core protocol should make the lives of users and administrators
simpler, barring the inevitable coding problems. We could
have made the locking protocol simpler, but then it would
have been as faulty and NLM/SM.

If you don't use locking (and real authentication,
ACLs, i18n, file streams, simultaneous UNIX/Windows
access to the same files, pre-epoch file
times, etc.), then I agree, NFSv4 buys  you personally nothing, and due to
implementation bugs, might initially be a step back. I'm a non-fan
of  file locking (an idea that Berkeley, Redmond, and
Summit should have resisted), but that genie is out of the
bottle, and it is time for a file access protocol that
does a proper job of support for locking.

You can ignore NFSv4's enhancements until NFSv3 goes away
(not for a long time I fear). When that day comes, I expect
NFSv4 implementations to be as solid as NFSv3
implementations are today, especially for the limited set of
functions you need.
Summit, NJ should have tried harder to resist ), but I recognize as an
NFS developer that users want and expect it, and
if NFS doesn't provide it, users will invent other
schemes above NFS, and those schemes won't work.

I don't think NFSv3 is going away soon though, so you are
free to ignore NFSv4 for several years, by which time the few
functions in NFSv4 that you do need ought to be available
in products as solid as your NFSv3 implementations.

 > I also don't think that IETF needs to standardise zero-copy
 > implementation
 > methods.  It did not need to do so with TCP.  It does not need to do
 > so now.

It sounds like you need to make these arguments in the RDDP wg.

 > Clever implementers will figure out a way to minimise those costs.  Less
 > clever implementers might not.  Either way, the protocol doesn't need
 > to change.

The worst case scenario:

If the RDDP wg and Transport Area directorate are wrong, then
we will surely see NFSv4 (and other ULPs) implementations
that perform well on 10G over pure TCP. Those implementations
will win, and RDDP will be yet another protocol that no one uses.

Perhaps the charter should make it clear that any  extensions to NFSv4 to
use direct data placement should not be required to use other unrelated
extensions. I'm certainly approaching v4.1 with that constraint.

    -mre

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 12 Dec 2002 14:22:22 -0800

R. J. Atkinson wrote: 
> On Thursday, Dec 12, 2002, at 16:31 America/Montreal, Robert Thurlow 
> wrote:
> >  We're making these
> > changes because we have a charter to do so and consensus on
> > what the changes are, and we hope to arrive at a better place.
> 
> It really scares me that anyone uses the charter permitting the
> work as the justification for the doing the work.  By this reasoning,
> if I'm permitted to walk off a cliff, therefore I must do so
> and hope to arrive at a better place.

This is a complete mis-statement as the text you yourself quote 
above shows.  Rob gave three reasons to make certain changes 
(whatever they are, I don't even know at this point), only
one of which was the fact that the charter permitted them.  He said
we are doing X because of A (permission), B (consensus), and C
(motivation).  Then you say it scares you when someone says they
are doing X because they have A (permission).  That might be 
scary if it were the case but it isn't.  Clearly, the issue
of permission is relevant here, as you would be the first to
say if the charter denied permission for those changes.  So
Rob was quite reasonable in mentioning it as part of the 
discussion, but it was certainly not given as the sole or 
even the major reason to make them.

I see that there is no intent to deceive here.  You quote the 
text that shows your interpretation (if I can call it that) is 
way off-base.

Nevertheless, the facts of the matter are clear, or should be,
to anyone.

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 13 Dec 2002 08:14:56 -0800

> On Thursday, Dec 12, 2002, at 19:09 America/Montreal, Talpey, Thomas 
> wrote:
> 
> > At 04:41 PM 12/12/2002, RJ Atkinson wrote:
> >> OK, so there is implementation experience that RPC is the only thing
> >> that needs changed.  Could we please at least write the charter
> >> modification text to limit potential damage (I mean, changes) to
> >> the RPC layer ?
> >
> > Huh? _Charter_ an implementation choice??
>
> Many IETF WGs have been chartered with narrow charters permitting
> a narrow scope of work (change foo but not bar in order to make
> frobnitz work over some new technology).
> 
> Folks other than me have agreed that it is feasible to do this
> with changes being restricted to the RPC layer, which provides
> greater stability to the NFS spec, promotes good modularity,
> and should reduce the interoperability impact of changes.

Why would one expect that making changes in an LLP that is used
by many other protocols, would *reduce* the interoperability impact 
of changes?  Other things being equal, I would expect that strategy
to increase the interoperability impact of the changes.  I'm
not saying that is a killer argument.  We need to look at the 
details to see what the effect is, which I would assume that the
working group would do in due course. 

I think we should do this in the best place, on modularity and 
other grounds (e.g. performance).  I accept that this is possible 
to do at the RPC layer and it clearly is possible at other layers
as well.  I think the working group has a good chance of picking
(i.e. coming to a consensus on) the right layer (i.e. agreeing
with me :-).  You clearly think that the group will make the
worst choice, as it has, in your opinion, on almost every other 
issue.  

> It is pretty commonly done in the IETF.