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.