Subject: Fwd: NFS over TCP stuff

From: RJ Atkinson <[email-masked]>
Date: Thu, 18 Jul 2002 23:07:11 -0400

Something to consider (that I maybe should point out) is that my 
network
situation is often a bit different from other folks'.

	I regularly am behind a low-bandwidth link into a public WAN using 
an IPsec VPN
(IPsec endpoints are in my basement and at HQ) to connect to several NFS 
servers
that are on the opposite coast of the US.  Bandwidth saved from NFS 
re-sending
big blobs can be a high percentage of my total uplink capacity (and I'm 
concurrently
doing other stuff besides NFS that really can use that uplink capacity).
There are occasions when I have as much as shared-T1 into the public 
Internet,
but more typically I've got 128Kbps shared uplink into the public 
Internet.

	This is likely different from the situation in many people's minds,
such as LAN with 10/100baseT to the desktop and maybe a 100/1000 
Ethernet interface
into the NFS server in the same building, often to an NFS server on the 
same floor
of the same building.

	I would gently suggest that one reason I'm using NFS/TCP for my 
situation
is that SMB is totally unworkable (way too chatty on the wire and way too
intolerant of high latency paths).  So this is an area where NFS already 
has some
advantages and could have a lot more operational advantage for little 
implementation
cost.

Thanks for listening,

Ran
[email-masked]

---

From: Mike Eisler <[email-masked]>
Date: Thu, 18 Jul 2002 21:43:18 -0700

> but more typically I've got 128Kbps shared uplink into the public

Right. I was in a worse position 6 years ago, where the
NFS/TCP client implementation I had a hand in worked very poorly
compared
to NFS/UDP over 14.4 kbit/sec link. As I result I rewrote most
of the code that dealt with timeouts. I wish I had had the time to
implement the proposal I posted to this list. 

All one has to do is turn on the packet sniffer over a low
bandwidth link to see what Ran and I mean ... the low hanging fruit is
pretty
obvious.

And over a low bandwidth link, there is nothing superior to a hard
mounted NFS/TCP mount for file transfers, but there's even more
bandwidth to get with some simple coding changes.

	-mre

---

From: Eric Werme USG <[email-masked]>
Date: Fri, 19 Jul 2002 10:47:53 -0400

>         I regularly am behind a low-bandwidth link into a public WAN using
...
   
   Right. I was in a worse position 6 years ago, where the
   NFS/TCP client implementation I had a hand in worked very poorly
   compared
   to NFS/UDP over 14.4 kbit/sec link.

Do you two remember the typical latencies you had for an I/O request on
an idle connection and after several other read/writes were in progress?
What sort of rsize, wsize did you use?  I'd imagine you'd set that smallish
so that telnet et al would remain usable.  And what retransmit timeout did
NFS use?

	-Ric

---

From: Mike Eisler <[email-masked]>
Date: Fri, 19 Jul 2002 11:15:41 -0700

> an idle connection and after several other read/writes were in progress?

I remember ping responses were 300 ms.

> NFS use?t

The point was to get good performance out of the box and not assume
the enduser was an NFS guru. Lacking an
API to tell me what the link speed was,  I used the default rsize/wsize
of
32 KB. If one tcp connection is hogging bandwidth, it seems like the
job of the TCP protocol driver to cope. I've seen NFS/UDP
implementations
play the auto resize game, and it doesn't work.

When I started out, the retransmit timeout was 10 seconds. Bad.
After I rewrote the code, I effectively had a 180 second timeout.
The NFS client wait ups to three times, 60 seconds each, for a
a response before issuing a retry. Worked well on 14.4kbit,
129 kbit ISDN, and of course, 10 and 100baseT.