[HECnet] Old protocols in new ones

Paul Koning paulkoning at comcast.net
Sun Mar 28 06:48:23 PDT 2021



> On Mar 27, 2021, at 2:54 PM, Johnny Billquist <bqt at softjar.se> wrote:
> 
> Paul and me have lamented over this many times.
> 
> DDCMP assumes that the underlying transport mechanism is reliable. Both in terms of the ordering of data, the reliability of getting all data across, and no duplication, and so on...
> 
> UDP does basically not fulfill any of these requirements, making UDP a very unsuitable transport for DDCMP links.

No, you're confusing DDCMP and Multinet.

Multinet isn't a datalink protocol; it's merely a wrapper for the routing layer packets.  In particular, it wraps routing layer point-to-point sublayer packets.  THAT assumes a reliable data link.

DDCMP is en entirey different beast.  It provides that reliable data link, and it sits on top of an unreliable physical layer.  It handles packet loss mostly because it handles bit error, which causes packet CRC error and is handled by timeout and retransmit ("ARQ").

> ...
> But as far as DDCMP goes, you should essentially not use UDP as a transport. That is just bad. Use TCP instead. And then you're good.

No.  It's certainly ok to use DDCMP over TCP -- except that it has to deal with the oddity of doing both connect and listen concurrently.  But UDP works fine.

> 
>  Johnny
> 
> On 2021-03-27 11:40, Keith Halewood wrote:
>> Hi,
>> I might have posted this to just Paul and Johnny but it’s probably good for a bit of general discussion and it might enlighten me because I often have a lot of difficulty in separating the layers and functionality around tunnels of various types, carrying one protocol on top of another.
>> I use Paul’s excellent PyDECnet and about half the circuits I have connecting to others consist of DDCMP running over UDP. I feel as though there’s something missing but that might be misunderstanding. A DDCMP packet is encapsulated in a UDP one and sent. The receiver gets it or doesn’t because that’s the nature of UDP. I’m discovering it’s often the latter. A dropped HELLO or its response brings a circuit down. This may explain why there’s a certain amount of flapping between PyDECnet’s DDCMP over UDP circuits. I notice it a lot between area 31 and me but but much less so with others.

I need trace logs for that, because that isn't supposed to happen.

More precisely, DDCMP definitely (this is tested) handles random packet loss.  It will retry indefinitely, as do other DDCMP implementations.  But the routing layer has its own "hello" protocol which has a limited tolerance for blocked communication, so if there is a failure to communicate that lasts too long (the "listen timer") then you will get a link down.  For DDCMP, a fairly long hello timer (60 seconds or so) is recommended.

If you see something else, in particular anything that suggests packet loss isn't handled transparently, please let me see the trace data.

	paul




More information about the Hecnet-list mailing list