[HECnet] Old protocols in new ones

[Keith Halewood]

I have rewired my head a little. Dijkstra is often quoted, "GOTOs are harmful to one's health," and "teaching COBOL should be a criminal offence." I believe he (and others) had a few choice things to say about object-orientated design/coding. I wonder what he would have made of .NET and the legions of developers who know nothing about how anything REAL actually works. It's becoming more difficult to page this **** out of my head... and I am increasingly resenting having to page it back in for the day job.

I had been lulled into a false sense of security because two of the UDP-based DDCMP circuits I have (UK to Netherlands and London to Edinburgh) experience a single instantly recovered drop every few days. The problematic ones are/were a London to Sheffield connection and London to AWS and these appear to suffer a lot of drops, sometimes in rapid bursts. The former one has switched over to DDCMP over TCP and I'll request the others move over too.

I have problems with GRE that I can solve with IPv6, but I have some lingering problems with IPv6 to solve first. Besides, I have some reengineering to do with a (now) TCP-based 'star coupler' before VAX/VMS becomes 'unavailable' to us mere hobbyists.

Moan moan moan

-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: 28 March 2021 00:03
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Old protocols in new ones

On 2021-03-27 21:51, Thomas DeBellis wrote:
> I was wondering whether the problem of running DDCMP over UDP might be 
> one of error timing.  If you blew it on a KMC or DUP, the hardware 
> would let you know pretty quick; milliseconds.  The problem with UDP 
> is how soon you declare an error.  If you have a packet going a long 
> way, it might take too long to declare the error.  It's a thought, but 
> you can get delays in TCP, too, so I'm not sure if the idea is half-baked.

No. It's not any timing problem.
It really is the fact that UDP packets can, and will get lost from time to time.
DDCMP is assuming that no packets get lost.
Reordered packets is sortof the same kind of problem.
As is duplicated packets.

All are bad, and DDCMP barely detects that it happens, and the only remedy is to tear down the link.

Run DDCMP over TCP instead, and all is good. Timing don't really matter that much.

   Johnny

> 
> On 3/27/2021 1:59 PM, John Forecast wrote:
>>
>>> On Mar 27, 2021, at 11:06 AM, Mark Berryman <mark at theberrymans.com 
>>> <mailto:mark at theberrymans.com>> wrote:
>>>
>>> DDCMP was originally designed to run over intelligent synchronous 
>>> controllers, such as the DMC-11 or the DMR-11, although it could 
>>> also be run over async serial lines.  Either of these could be local 
>>> or remote.  If remote, they were connected to a modem to talk over a 
>>> circuit provided by a common carrier and async modems had built in 
>>> error correction.  From the DMR-11 user manual describing its features:
>>> DDCMP implementation which handles message sequencing and error 
>>> correction by automatic retransmission
>>>
>>
>> No. DDCMP was designed way before any of those intelligent 
>> controllers. DDCMP V3.0 was refined during 1974 and released as part 
>> of DECnet Phase I. The customer I was working with had a pair of 
>> PDP-11/40’s, each having a DU-11 for DECnet communication at 9600 bps.
>> DDCMP V4.0 was updated in 1977 and released in 1978 as part of DECnet 
>> Phase II which included DMC-11 support. The DMC-11/DMR-11 included an 
>> onboard implementation of DDCMP to provide message sequencing and 
>> error correction. Quite frequently, customers would have a DMC-11 on 
>> a system communicating with a DU-11 or DUP-11 on a remote system.
>>
>>   John.
>>
>>> In other words, DDCMP expected the underlying hardware to provide 
>>> guaranteed transmission or be running on a line where the incidence 
>>> of data loss was very low.  UDP provides neither of these.
>>>
>>> DDCMP via UDP over the internet is a very poor choice and will 
>>> result in exactly what you are seeing.  This particular connection 
>>> choice should be limited to your local LAN where UDP packets have a 
>>> much higher chance of surviving.
>>>
>>> GRE survives much better on the internet than does UDP and TCP 
>>> guarantees delivery.  If possible, I would recommend using one these 
>>> encapsulations for DECnet packets going to any neighbors over the 
>>> internet rather than UDP.
>>>
>>> Mark Berryman
>>>
>>>> On Mar 27, 2021, at 4:40 AM, Keith Halewood 
>>>> <Keith.Halewood at pitbulluk.org 
>>>> <mailto:Keith.Halewood at pitbulluk.org>>
>>>> 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