Old protocols in new ones --> Anf10 - HECnet

27 Mar 2021

Yes, ANF10 also uses Ddcmp.
On simh Anf10 also uses the Dmr/Dmc implementations.

RV

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

On 2021-03-27 18:59, 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. 
Right. Smart controllers with DDCMP in firmware on the controller itself 
was definitely not the first implementation.

But I don't have the full history of DDCMP as such. But it sounds 
reasonable that the original DECnet could have been using DDCMP already. 
But was that the first implementation of DDCMP? You mentioned V3.0, 
which would imply that there were even older versions since before DECnet.
Did ANF-10 use DDCMP?

   Johnny

...

    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