[HECnet] What use are *you* making of HECnet?

On Thu, 26 Feb 2009 14:19:35 +0100, you wrote: As for fragmentation... Now I assume you are talking about the encapsulation of ethernet packets in UDP packets. Those will be a bit larger still, and will almost certainly be fragmented when sent over the internet, yes. I don't see a problem with that. Do you? Really, we [1] had some problems with fragmented UDP packets, mostly due to some cheap IP routers bundled with local ADSL connections. Many of them seem to be unable to correctly manage UDP fragments and/or have memory leaks which in the end cause lockups and other nasty things after some DECnet-in-UDP traffic has passed thru them. In at least one case, the problem was even nailed down to some ISP apparatus sitting between two remote bridges of ours. The most common symptom is a working connection (as long as it's used only for interactive light traffic such as CTERM) which hangs when used for bulk data transfers like file COPY. In one specific case, a system with a very complex announce text (the one shown before login) was actually unreachable because the contents of the announce were so large that they caused a fragmented UDP packet to be sent, leading to a SET HOST hang without "Username:" prompt. Our solution was to reduce the overall size of DECnet packets. This is for the actual live DECnet (not permanent across network restarts): $ MCR NCP SET CIRC SVA-0 STATE OFF $ MCR NCP SET LINE SVA-0 STATE OFF $ MCR NCP SET LINE SVA-0 BUFF SIZE 1456 $ MCR NCP SET LINE SVA-0 STATE ON $ MCR NCP SET CIRC SVA-0 STATE ON This to make it a permanent change: $ MCR NCP DEF LINE SVA-0 BUFF SIZE 1456 The actual line/circuit name (SVA-0 in the above examples) can be seen with: $ MCR NCP SHOW KNOWN LINE $ MCR NCP SHOW KNOWN CIRC The 1456 bytes value was chosen (after some trial-and-error with tcpdump) so to have 1492 bytes long UDP packets, which is exactly the local MTU of our ADSL links. One of us had to trim even more its buffer size, down to 1428. We don't know why, but that was the biggest size he could use without incurring in DECnet link hangs. The latter appears to be a ISP-side problem with UDP. We still do not know how these UDP related problems would/will impact other protocols like LAT, LAD/LAST and MOP because we haven't experimented so much as with pure DECnet. Any contribution and suggestions on how to force reduced frame size for those protocols would be much appreciated. :-) Hope this helps, G. [1] http://decnet.ipv7.net/