Re: [nfsv4] channel attribute negotiation

["J. Bruce Fields" <[e-mail]>]

On Mon, Oct 11, 2010 at 06:18:12AM -0700, Mike Eisler wrote:
> 
> On Sat, October 9, 2010 7:52 am, J. Bruce Fields wrote:
> > I noticed a couple small typos as I was reading the discussion of
> > channel attribute negotiation in 5661 section 18.36.3:
> >
> > 	- The heading of the dicussion should be
> > 	  "csa_fore_chan_attrs, csa_back_chan_attrs:"
> > 	  not
> > 	  "csa_fore_chan_attrs, csa_fore_chan_attrs:"
> > 	- "with more operations than ca_maxoperations" should be "with
> > 	  more operations than the negotiatiated maximum".
> 
> Please report these as errata to ensure that RFC5661-bis corrects these.

OK, done.

> > Some clarification in the case of ca_maxoperations might be useful: is
> > the client expted to send a hopeful value (hey, let me send you
> > thousands of ops!) or the minimum value that it needs to function (e.g.
> > number of operations it requires to send its open compound)?  The linux
> > client currently does the latter.
> >
> > The latter seems the more important number to communicate, so perhaps we
> > should advise clients to send their required minimum, and servers to
> > decrease the client-proivded number only with the understanding that
> > this may prevent the client from continuing.
> 
> Sure but in a client insists it needs one million ops per request, this is
> a meaningless distinction.

Yeah, to make the question interesting you'd have to imagine a client
that, say, needed 8 ops per compound to function, but could take
advantage of a few optimizations if it got 16.  And a server
implementation which cared much how many it gave up.

> What we get when the session is created is an unambiguous agreement about
> what can be supported on each channel. I'm open to ideas about how we
> could do better.

Fair enough.  Thinking about it some more, there may be a little
ambiguity here, but probably nothing worth worrying about.

--b.