[HECnet] Old protocols in new ones

Johnny Billquist bqt at softjar.se
Sat Mar 27 11:54:46 PDT 2021


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.

TCP, on the other hand, perfectly match these requirements.

Unfortunately, Multinet is basically using UDP as a transport for a 
DDCMP link. Which is obviously bad and wrong. Multinet can also use TCP, 
in which case you're good.

My bridge implementation is carrying DECnet traffic as well, but is then 
appearing no different than an ethernet link, in which delivery is no 
longer guaranteed. And there I use UDP, and in this case, it does make 
sense. DECnet over ethernet behaves differently than DECnet over DDCMP.
(The bridge have a scaling problem on the other hand, so you don't want 
the bridge to span a too larger virtual ethernet, since a lot of traffic 
will go everywhere.)

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.

   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.
> 
> In the old days, DDCMP was run over a line protocol (sync or async) that 
> had its own error correction/retransmit protocol, was it not? So a 
> corrupted packet containing a HELLO would be handled at the line level 
> and retransmitted usually long before a listen timer expired?
> 
> Are we missing that level of correction and relying on what happens 
> higher up in DECnet to handle missing packets?
> 
> I’m having similar issues (at least on paper) with an implementation of 
> the CI packet protocol over UDP having initially and quite fatally 
> assumed that a packet transmitted over UDP would arrive and therefore 
> wouldn’t need any of the lower level protocol that a real CI needed. TCP 
> streams are more trouble in other ways.
> 
> Just some thoughts
> 
> Keith
> 

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


More information about the Hecnet-list mailing list