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

[gerry77 at mail.com]

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/