[HECnet] Old protocols in new ones

[John Forecast]

> On Mar 27, 2021, at 11:06 AM, Mark Berryman <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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20210327/1541f56d/attachment-0001.htm>