Subject: Re: interfaces, receive buffers, and NFS
To: Frank van der Linden <firstname.lastname@example.org>
From: John Hawkinson <jhawk@MIT.EDU>
Date: 04/03/2001 09:16:08
I don't think that the decision to raise the nfs read/write size
from 8k to 32k should be governed exclusively by host-side
For NFS in environments where it crosses a router, or [help us!]
a WAN, a 32k fragmented UDP packet can be far more severe than
an 8k one, because it may be substantially more likely
that the drop of a single fragment will occur, for two reasons:
1) 8k is 6 packets at a 1500-bte mtu, and 32k is 22 packets. A
5% loss rate means you drop 1 fragment in each 32k udp packet,
i.e. complete nonfunctionality. You needed 16% loss to get that
with 8k. A more modest 1% packet loss results in 22% udp loss
at 32k, and only 6% loss at 8k.
2) Routers are more likely to drop multiple trains of packets
in immediate succession, than those that are spaced out. (cf.
tail drop vs. RED gateways). This is worse the larger the train
of packets is.
I recognize it would have been better to have raised these issues
when the original change happened. I'm sorry I didn't notice then.
Have you considered these issues? I think they're important,
perhaps important enough to get discussion in a man page. I
note we don't have an nfs(4) -- too bad. At lesat some discussion
under mount_nfs(8) under -r and -w, though.
I also don't see anything about this in doc/CHANGES. Could you
please make sure it gets updated when we see final resolution?