[HECnet] Old protocols in new ones

[Wilm Boerhout]

Keith,

I have followed the dialog wile entertaining the grandkids over the weekend. 

With them now gone, I am ready for a switch when you are. 

Wilm

(Verstuurd vanaf mijn telefoon, dus wat korter dan gewoonlijk.)
(Sent from my phone, so a bit more compact than usual)

> Op 28 mrt. 2021 om 13:00 heeft Keith Halewood <Keith.Halewood at pitbulluk.org> het volgende geschreven:
> 
> 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