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

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 1:06 PM, Johnny Billquist <bqt at softjar.se> wrote: On 2021-03-27 18:59, John Forecast wrote: 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 -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se <mailto:bqt at softjar.se> || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On Mar 27, 2021, at 3:06 PM, Johnny Billquist <bqt at softjar.se> wrote: ... 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?

On Mar 27, 2021, at 4:51 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote: I believe our site had three situations. Our DN20's had both KMC's and DUP's. The KMC's were used for local computer center communications of 10 to 30 feet (the 20's were running in a star configuration). The DECnet of the time was reliable enough until you put a continuous load on the KMC's. If you wanted to guarantee transmission, then you had to write an application level protocol on top of that to declare a connection down and to renegotiate. This still works with the inconsistent NI implementation on KLH10.

I do not recall whether we ever determined where the problem was; the Tops-20 DECnet III implementation of the time, the DN20 (MCB) or the KMC. I don't recall what the KMC had for hardware error detection; since the lines were synchronous, I would imagine it would flag certain framing errors, at a minimum. The DN20's were left largely unused once we got NI based DECnet, whose performance blew the KMC right out of the water. The CI speeds were just about incomprehensible for the time. We put timing code into our transfer application, but I can't remember the speeds but they were highly admired. We had considered removing the DN20's, but conservatively kept them as a fail-back in the case of a CI or NI outage. The other reason was for the 'non-local' lines that ran to other parts of the campus and long distance to CCnet nodes. These both used DUP's. I can't remember how the campus lines were run, but the long distance was handled by a pair of 9600 baud modems on leased lines. I can't remember how the modem was configured; synchronous or asynchronous. In the case of the DUP's, there were plenty of errors to be had, but they were not as highly loaded as the KMC's, which were saturated until the NI and CI came along. The third case was that of the DN65 to talk to our IBM hardware. That was data center local and ran a KMC. The protocol that was spoken was HASP bi-sync. I don't recall what the error rate was; HASP would correct for this. A bucketload of data went over that link. While I had to mess a tiny bit with the DN60 PDP-11 code to change a translate table entry, I don't remember that I had to fiddle with the DN60 that much. IBMSPL was another thing entirely; we were an early site and I had known one of the developers at Marlboro. It had some teething problems, but eventually was fairly reliable. 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 >> >

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

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

On Mar 27, 2021, at 2:54 PM, Johnny Billquist <bqt at softjar.se> wrote: Paul and me have lamented over this many times. DDCMP assumes that the underlying transport mechanism is reliable. Both in terms of the ordering of data, the reliability of getting all data across, and no duplication, and so on... UDP does basically not fulfill any of these requirements, making UDP a very unsuitable transport for DDCMP links.

... But as far as DDCMP goes, you should essentially not use UDP as a transport. That is just bad. Use TCP instead. And then you're good.

Johnny On 2021-03-27 11:40, Keith Halewood 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.

On Mar 28, 2021, at 12:59 PM, Robert Armstrong <bob at jfcl.com> wrote: Johnny already said it, but it's worth repeating that Multinet WILL do DDCMP over TCP (yes, TCP not UDP) if you ask it to. It's unfortunately not the default, but it's easy to change. Bob

I have always wondered whether 'Multinet' might have been a figment of some marketeer's imagination.? DEC's sales people had some remarkable gaffs, particularly when transitioning from the 36 to 32 bit line.? But I'm sure they were not unique in that regard. Under Tops-20, 'Multinet' has a _very_ specific meaning; it is the MNETDV module (the Multinet driver) is what handles routing IP packets over different physical media, in this case, an AN20 (to an IMP), an NI and CI. I can't remember what equivalent for DECnet is called in 36 bit land, but it can be routed over a CI, an NI or over a DTE to DN20 (MCB). There are some additional devices, but I don't know if they were implemented; I think ROUTER.MAC handles some of that. > ------------------------------------------------------------------------ > On 3/28/2021 1:52 PM, Paul Koning wrote: > > I didn't see that. > > I have never used the product called Multinet myself. When I use the term "Multinet" it has always referred to the encapsulation of DECnet point to point routing packets with a 4 byte header, sent either as UDP packets or over a TCP stream. This is what I understand to be the so-called "Multinet datalink" (which as I have said many times isn't an actual datalink and reflects only the utter ignorance of its creators). That "protocol" should be avoided; if there is no alternative then only the TCP variant should be used. The UDP variant is utterly unfit for any use in any application whatsoever and always has been; I should probably delete it from PyDECnet rather than permit it with a warning as I currently do. > > If the product called Multinet also supports DDCMP, that's a different matter entirely. I have never heard of any such thing. How does it work? Is it compatible with DDCMP over TCP as implemented in SIMH? If yes -- and even if it only supports only connect or listen but not both concurrently as SIMH does -- it should work with PyDECnet. I'd be interested in hearing about it. If it isn't compatible with the SIMH version for some other reason, then I would expect it not to work with PyDECnet either. If so, and if someone can supply me with a description of how it operates, hopefully with at least some protocol captures, I may be able to add support for it. > > paul >> ------------------------------------------------------------------------ >> On Mar 28, 2021, at 12:59 PM, Robert Armstrong<bob at jfcl.com> wrote: >> >> Johnny already said it, but it's worth repeating that Multinet WILL do DDCMP over TCP (yes, TCP not UDP) if you ask it to. It's unfortunately not the default, but it's easy to change. >> >> Bob >>> ------------------------------------------------------------------------ >>> Paul Koning<paulkoning at comcast.net > wrote: >>> No, you're confusing DDCMP and Multinet. >>> Multinet isn't a datalink protocol; it's merely a wrapper for >>> the routing layer packets.

On Mar 28, 2021, at 3:33 PM, Johnny Billquist <bqt at softjar.se> wrote: ... And at least in RSX, there is no generic "point-to-point" type of link. The types that exist are: . DDCMP . Bisync . SDLC/ADCCP/HDLC . X.25 . Ethernet . Hardware protocol Where hardware is a bit like just saying that the hardware does something, and it's good enough. No software required, and it will work. But all except ethernet are more or less point-to-point. But DDCMP can also be used for multidrop connections. The others would imply point-to-point, but will have possibly have different other software layers added to handle the specifics of that link protocol.

And in my case, I chose to claim to DECnet that the Multinet links are DDCMP, but without having a software DDCMP layer required. But that was just because I had to pick something in RSX. And this adds to my occasional confusion about DDCMP and DECnet link management.

Right. Well... It handles transmission errors through CRC. It handles packet loss also by using sequence numbers for packets. (Otherwise, a fully lost packet would not be detected. CRC don't spot such things.)

Right. My bad. I was totally mixing up DDCMP with the DECnet routing layer and link managment. As far as using TCP, that comes down to the problem of how to establish the link in the first place. It's outside of DDCMP itself, and is no different than if you were to run DDCMP over a dial up line. Only one side is supposed to dial the number, while on the other side you would be answering the incoming call. But yes, you need some way to tell which end should be listening, and which end should do the connecting.

On Mar 28, 2021, at 4:40 PM, Johnny Billquist <bqt at softjar.se> wrote: On 2021-03-28 22:10, Paul Koning wrote: That list was pulled out from the actual DECnet/RSX sources. It's not any arbitrary, or generic description of DECnet or links, but trying to tell you what is in RSX.

Technically, TCP should work just fine. But yes, Multinet even have some funny specific behavior making even TCP a bit tricky.

It's really annoying how they seem to have gone out of their way to make it harder. But we've talked about this before. Right. And we can't do it anyway, since the existing VMS implementation is the way it is, and won't change. If I want to, I could do something on the RSX side which would be more appropriate, and you could obviously do that also in PyDECnet. But we'd still have to deal with the broken VMS ways... But I wouldn't actually model it according to ethernet. For a TCP connection, a ptp link is the perfect way to look at it. And I wouldn't probably use UDP at all. But if I would, then yes, it would be modelled as a broadcast link, even though there would only ever be two points to it.

... Yeah. I wouldn't do it that way. That is ugly. Better to designate one as the connector and the other as the listener.

I mean, really. This was already regarded in that same way already in the real world back then. Dial up modems as well as X.25 are the exact same type of thing. Both sides cannot initiate the connection. One is the initiator, and the other the one accepting the connection.

On Mar 29, 2021, at 2:25 AM, Johnny Billquist <bqt at softjar.se> wrote: On 2021-03-28 23:08, Paul Koning wrote: I'm not sure what you think the problem is here. This would be interesting to explore. Restart notification, in my ears, seems to be about informing DECnet if the link had to be restarted. Which, I would say, obviously can be done with Multinet over TCP, because this is detected/handled by TCP just fine. And if the TCP connection is lost, all you need to do is just inform DECnet that the link went down. And I do exactly that with TCP connections.

What else is there, that you think is a problem? My problem, on the other hand, is that Multinet isn't just setting up the TCP connection, and then let things run. Multinet seems to explicitly want also one side to be the first to start communicating, and seems to drop packets if things don't happen in the order Multinet thinks they should happen. Which is really annoying, since DECnet should just be let alone to sort it out. So I've had to start trying to play more like Multinet, designating one as the active, and the other as the passive, and at connection time, delay signalling based on this, in order to play nicely with VMS.

... Well, your restart mechanism is something I do not understand. I would just run the TCP connection straight as it is. If the connection is closed, for whatever reason, this should be signalled to DECnet just like DDCMP signals link errors, and when the connection is established, data just flows again. It should work just fine without any further stuff. This is pretty close to what I do today, with the unfortunate extra fluff required since Multinet don't like if the "wrong" side talks first.

I would not send DMC payloads. Seems like an unnecessary extra step/layer with no added value.

GRE basically just encapsulate ethernet packets anyway. (Yes, I know it can encapsulate other things, but anyway...)

On Mar 31, 2021, at 5:42 PM, Johnny Billquist <bqt at softjar.se> wrote: On 2021-03-31 23:01, Paul Koning wrote: [...] Ah. Now I understand you. Basically, the actual VMS Multinet implementation is the problem. Not running DECnet over TCP as such. Then I fully agree with you. The VMS Multinet is just strange. And you mentioned another thing that I have also observed. If the TCP link goes down, it appears as if the VMS side actually don't get a circuit down, and then things behave strange when the link comes up, with init packets coming at strange points. This all leads to it taking longer than I would expect should be required to reestablish the link when VMS Multinet is involved. That's why I said "Technically Multinet over TCP should work fine". It should work fine, but in reality it don't because VMS Multinet is doing strange things for no good reason (that I can figure out). Had they just used what TCP provides, and signaled the information to DECnet, it would have worked without a hitch.

On Mar 28, 2021, at 4:40 PM, Johnny Billquist <bqt at softjar.se> wrote: On 2021-03-28 22:10, Paul Koning wrote: That list was pulled out from the actual DECnet/RSX sources. It's not any arbitrary, or generic description of DECnet or links, but trying to tell you what is in RSX. As I mentioned. It basically just assumes the hardware does something. Basically, DECnet/RSX don't have a clue, and do not get involved, leaving it all to some hardware. There are no specific details that can be deduced further for that one. But it is one of the possible values to assign to a line type.

Obviously, GRE does not exist in the DECnet/RSX world. :-) Technically, TCP should work just fine. But yes, Multinet even have some funny specific behavior making even TCP a bit tricky. It's really annoying how they seem to have gone out of their way to make it harder. But we've talked about this before. Right. And we can't do it anyway, since the existing VMS implementation is the way it is, and won't change. If I want to, I could do something on the RSX side which would be more appropriate, and you could obviously do that also in PyDECnet. But we'd still have to deal with the broken VMS ways... But I wouldn't actually model it according to ethernet. For a TCP connection, a ptp link is the perfect way to look at it. And I wouldn't probably use UDP at all. But if I would, then yes, it would be modelled as a broadcast link, even though there would only ever be two points to it. Right. And 255 outstanding packets is plenty in this case, I think. Yeah. I wouldn't do it that way. That is ugly. Better to designate one as the connector and the other as the listener. I mean, really. This was already regarded in that same way already in the real world back then. Dial up modems as well as X.25 are the exact same type of thing. Both sides cannot initiate the connection. One is the initiator, and the other the one accepting the connection. Johnny -- 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