[Nottingham] Odd behaviour in KDE

[Robert Davies]

On Thursday 21 Aug 2003 14:24, Lee wrote:
> > My suggestion was based on a common NFS tweak where there are problems. 
>
> Really? you'd think nfs would just request the 'missing' packet rather
> than the whole segment? I'm sure this does'nt happen with tcp, but I
> nfs/udp is built for throughput rather than error recovery, at least
> there's lot of cool option to tweak with nfs....god I know why I hate
> smb so much now....

NFS doesn't know what the MTU is, and with the path discovery technique, that 
number would be meaningless anyway.  It has to rely on the networking layers 
to handle the packet assembly and fragmentation issues.  It's a +ve feature 
of UDP/IP that the application is  responsible for retransmissions for error 
recovery.   If NFS simply used as a maximum, the RFC recommended minimum 
supported UDP packet size,  that would result in 16 packets for each Unix 
filesystem block which would also be sub-optimal.  I remember one case where 
TCP/IP was hiding broken hardware flow control on a modem :)  It would adapt 
to exactly the rate that worked, to avoid the modem needing to stop the 
host's transmission.

NFS was designed for Lan's.  There you actually want to know, if they get 
unclean and do something about it, rather than degrade gracefully and 
imperceptibly.  I might try  out one of the Internet capable protocols soon, 
was thinking about Intermezzo.  I have a machine installed for my Sister, and 
it would be useful for on-demand data transfer, rather than regular polling 
with rsync(8).

Actually quite a few ppl suffered data corruption with NFS, because by default 
UDP checksums were turned off in SunOS 4, fine in Ethernets and over X.25, 
but when fast serial lines started getting used without the Level 2 
protection, the problems soon  showed.

TCP re-orders and checks the transmission in kernel memory.  This implies 
buffering resources, so it can simply retransmit missing packets.  Though if 
the IP layer fragrments the packet, then the whole of that would be 
re-transmitted, as there's no way the sender can know which fragment was 
dropped.

Some protocol with notification of corrupted packets, requesting resends, 
probably would be open to DoS attacks I guess.

> Interesting stuff, aint nfs just so much smarter than smb, it would be
> great if nfs had better security.. 

NFS security was meant to be achieved via secure RPC calls.  Due to Co-Com 
export restrictions though, Sun couldn't export a software encryption 
implementation, or their hardware crypto-chips, which made for an empty slot 
in most European workstations.  Friendly governments were able to source 
those chips, for use by military etc  I know because colleagues in 
Switzerland, were consulting in certain sites where you needed security 
vetting.

> Packet loss during the inital tcp 3 way handshake could be real bad

Won't the connection attempt simply be retried?

> What we need is wireless tcp... perhaps, and get away for this god awful
> layer 2 retransmittion system than 802.11b has... it's like shooting
> flea's with a machine gun.....

A believer in end to end protocols :)  How does 802.11b's retransmission 
operate?

> it's only when you really look a tcp this close, that you find it really
> is not that clever..but it works....we just need bigger pipes, and less
> people using microwave oven's....hahaha

Oh it is actually really very clever, it's really hard to design something 
that is  simple and elegant enough to implement well.  Most applications that 
start off UDP/IP end up with a TCP/IP option, because it's really quite hard 
to do a better job.

Rob