Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!think!ames!sdcsvax!ucbvax!TOPAZ.RUTGERS.EDU!hedrick
From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Internet Protocol #77
Message-ID: <8707150135.AA01091@topaz.rutgers.edu>
Date: Tue, 14-Jul-87 21:35:47 EDT
Article-I.D.: topaz.8707150135.AA01091
Posted: Tue Jul 14 21:35:47 1987
Date-Received: Fri, 17-Jul-87 01:37:55 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 14

You indicate that there is a maximum acceptable delay for NFS.  That's
not quite the case.  NFS does not adjust its timeouts and
retransmission times dynamically on a per-connection basis as TCP
does.  However you can set the constants as options in the mount.  It
should be possible to use NFS over connections with a long delay, as
long as the system administrator is able to choose reasonable values.
(A connection where values changed a lot would be a problem, of
course.)  This is obviously not the best way to design a protocol.  On
the other hand, they needed higher speed than is typical with TCP.
The evidence from this mailing list is that the commonly-used
techniques for choosing retransmission times and the like do not
always lead to the best results.  So I can understand a pragmatic
decision to optimize for local Ethernets and let the administrator
tune it for other connections.