Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!mcvax!ukc!strath-cs!jim
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.protocols.nfs
Subject: Re: Suggestion for improved NFS monitoring
Keywords: retries, xids
Message-ID: <1287@stracs.cs.strath.ac.uk>
Date: 6 Dec 88 12:23:58 GMT
References: <773@sequent.cs.qmc.ac.uk>
Reply-To: jim@cs.strath.ac.uk
Organization: Comp. Sci. Dept., Strathclyde Univ., Scotland.
Lines: 57

In article <773@sequent.cs.qmc.ac.uk> liam@cs.qmc.ac.uk (William Roberts) writes:
>... Suggesting a scheme for determining retried NFS request packets.

>1) All original xids have most & least significant byte = zero
>2) All retry xids have most and least significant byte = ones

>Does anyone think this is a good idea? Do you want to be able
>to identify retries on the server?

I don't think this is a bad idea, but I don't think it would help much.

The real problem with NFS is the absence of almost any flow-control at
any stage of the protocol stack - ISO Reference Model or ARPA Reference
Model, call it what you like. The NFS protocol should *somewhere*
provide a means for clients and servers to say "slow down, you're going
too fast for me". Where this should go is a religious issue - my
preference would be for something at the UDP/transport level. Naturally,
any notion of flow control further complicates the 'statelessness' of an
NFS server.

I see that Version 3 of the NFS protocol has now been published. I've
not had a chance to look at it in detail yet. It does appear to go some
way towards dealing with this problem. Here's one of the error codes
(what a glorious name!) defined in the new edition of the protocol:

	NFSERR_JUKEBOX = 30
        	Slow down, buddy. The server has detected a retransmission
        	of a request that is already in progress.

As far as I can see, the spec. doesn't say what a client should do (or
not do) when it gets this error returned. Worse, there doesn't appear to
be any way that a client can ask the server to slow down, though an
overloaded NFS client should not be as much of a problem as an overloaded
server.

To get back to William's question, I don't think his idea will need to
see the light of day. To properly adopt it, the NFS protocol would need
to be redefined and Sun have just done that. The new version of NFS has
something about flow control. [Though it appears at first glance that
clients are free to ignore "slow down" messages from the servers.]

Hopefully the new protocol will go some way to make NFS more usable in a
genuinely heterogeneous environment. Administrators should just have to
fire up the NFS service and let the protocol figure out for itself just
how fast or slow it should go. [If TCP can do it, why not NFS?] It is
just not reasonable for users or system administrators to have to tinker
with things like numbers of biod and nfsd processes or experiment with
the increasingly more baroque options that are kludged into NFS mounts.

		Jim

-- 
ARPA:	jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk
UUCP:	jim@strath-cs.uucp, ...!uunet!mcvax!ukc!strath-cs!jim
JANET:	jim@uk.ac.strath.cs

"JANET domain ordering is swapped around so's there'd be some use for rev(1)!"