Subject: Re: Anything else not on the issues list?

From: Peter Staubach <[email-masked]>
Date: Thu, 18 Jul 2002 11:12:17 -0600 (MDT)

> 
> Mike pointed out at least one instance (slow links) where unnecessary
> retransmissions can effect perceived and real performance.  It seems
> that since the WG has addressed other Internet operation issues
> (inclusion of COMPOUND and mandatory security) that this proposal
> would also fall into that category.  Applications like telnet do not
> retransmit data do they?  Why should the RPC layer (as a user of TCP)
> retransmit requests when the connection is still operable.
> 

Well, applications such as telnet or ftp do not retransmit, period.
Perhaps that was not such a good counter example.

I think that this work would have been well and good when NFS over TCP
was first getting started, but now implementations exist with certain
semantics.  By specifying these new rules, however good they may be,
they create a different set of semantics which must be implemented to
_in addition_ to the existing set.  We can't change existing semantics
for NFS Version 2 and NFS Version 3 implementations.

> The other place where this can be helpful is with overloaded servers
> and their ability to clear requests.  Why should the server have to do
> more work just because it is slow.
> 

These problems can be solved in other ways, not just by doing this
work.

Is it positive that there is not now, nor every will be, a need for the
server to drop a request simply because it can not be handled correctly
at the current time?

Is this really such a large problem?  The TCP timeout is 60 seconds on
Solaris systems.  I suspect that it is about the same for other
implementations.  If the server can not handle a retransmitted request
at this interval, then something else is wrong and these retransmits
are not really going to matter.

The new semantics are going to cause complexity in the RPC layer and
cause it to have to know about different versions of upper level
protocols.  Do we really want to have to hardwire information about
NFS Version 4 into the RPC layer?

		ps

---

From: Peter Staubach <[email-masked]>
Date: Thu, 18 Jul 2002 11:19:45 -0600 (MDT)

> 
> I will ask it again.  Do applications like telnet retransmit their
> data because of a lack of response?  Why should RPC or NFS retransmit
> when the link is operational?
> 

Applications like telnet rely upon higher level entities to handle
retransmits if required.  NFS does not have this quality.  We have to
do the work to ensure that the data gets to where it should be,
reliably, and without corrupting it.

> > Not necessarily.  Currently, servers can shed load by dropping requests.
> > A requirement to transmit NFSERR_DROPPED replies would be more work.
> 
> Under Mike's proposal, the server can drop the entire connection if it
> is overloaded with work.  The is low overhead. :-) NFS4ERR_RESOURCE is
> already available to a server that has exceeded its resource capacity.
> 

Dropping TCP connections is certainly _NOT_ low overhead.  The http
folks con attest to this.  Dropping and reestablishing TCP connections
is serious business and will definitely cost in overhead.  It will
destroy and data transfer that was in progress and cause it to need
to be restarted from the beginning.

This is not a panacea for the evils of overloaded servers.

		ps

---

From: Peter Staubach <[email-masked]>
Date: Thu, 18 Jul 2002 13:54:46 -0600 (MDT)

> 
> Written this way, the advice to substitute a null call for a
> "fat" retransmission seems like good advice, particularly
> on a slow link - whatever the version of NFS.  
> 
> Has anyone tried it ?
> 

It "sounds" like good advice, but it would be interesting if anyone
has tried it.  If the need to retransmit is real, then there has been
a lot of extra work for little gain.  The retransmission has been
delayed by the null call latency and extra work was done by both the
client and the server.

Some real information here would be useful, instead of us all giving
opinions with no real facts behind them.

		ps