Re: [Re: NFS -current

Dan Nelson wrote:
> UDP works just fine on a switched network.  On my NFS servers I use an
> 8k rsize/wsize and UDP mounts on everything and have relatively few
> dropped fragments.

I'm not sure Ian's network is as reliable.  8-).

Nevertheless, you really do not want to use UDP for NFS with
a packet size larger than the MTU, relying on the fragment
reassembly, if you can avoid it.

The first problem is that the only NAK mechanism require that
the entire set of datagrams be discarded, and there is no
proactive discard for the datagrams in the reassembly queue
for the partial set that was received previously, prior to
an explicit request for retransmission.

Even assuming a perfect delivery media, such as in a switched
network in an area without electrical interference, and no
overloading to result in dropped packets, UDP is less efficient,
with an overdriven window, than TCP.

The main reason for this is that the TCP window is generally
larger than the commonly used rsize/wsize of 8K.  In addition,
with UDP, the transactions are all request/response, which
means you can't go onto the next 8K until the prior 8K was
received, whereas with TCP, you can have a full windowsize of
data in the pipe.

Server based predictive read-ahead works with TCP.

UDP packets are much easier for an attacker to spoof.

UDP packets are harder to get through firewalls.

UDP is not stateful, so it renders stateful firewalls vulnerable,
if it's allowed through.

In fact, the only legitimate argument I have ever heard for UDP
has been "I have an old Linux install that can't talk TCP, as
only UDP was implemented at the time I installed it".

I can't really understand the attraction to UDP.  Maybe it has
to do with the people involved being netrek players from way
back...

-- Terry