[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.

> 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 >> >