From: Peter Staubach (Peter.Staubach@sun.com)
Date: 07/18/02-12:12:17 PM Z
Message-Id: <200207181716.g6IHGQ111121@amunet.Central.Sun.COM> Date: Thu, 18 Jul 2002 11:12:17 -0600 (MDT) From: Peter Staubach <Peter.Staubach@sun.com> Subject: Re: Anything else not on the issues list? > > 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
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:58 AM Z CST