[HECnet] Old protocols in new ones

[Paul Koning]

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

It's certainly possible to define any number of data link types, with a wide variety of services.  Some are useable with DECnet, others are not.

DECnet puts data links into two categories, from the point of view of the routing layer: "point to point" and "broadcast".  Those names are deliberately generic, but a good way to think of them is "like DDCMP" and "like Ethernet".  DECnet also specifies what services it requires from the data link layer, for each of these two subtypes.

For broadcast, Ethernet, FDDI, 802.11, and 802.4 all meet the requirements.  802.5 does not because of its bogus addressing and bad implementation of multicast, but there is a modified version of Phase IV (called "IV prime") that was hacked to make it work with 802.5.

For point to point, DDCMP and X.25 are both DNA standard and work.  Among the others you mentioned, I would think that Bisync and SDLC/HDCL/ADCCP would work since they have comparable semantics.  "Hardware" does not appear to meet the stated requirements, not unless it has some sort of control wires like the modem control signals of RS-232 to deliver the "restart detection" requirement.

Then there is GRE, which was done as a broadcast datalink but differs in that it doesn't have addresses.  It works reasonably well because for a two-station connection you can live without having real addresses.  It does have the Ethernet protocol type field; living without that would be more painful though in theory still possible.

Multinet is quite another matter.  It claims to be a point to point datalink, but it doesn't obey any of the clearly written requirements of a point to point datalink.  That failure to conform is the reason it doesn't work right.  In the UDP case that is more obvious, but both versions are broken, it's just that the TCP flavor doesn't show it quite so often.

It would have been easier and far more correct to model the Multinet datalink as a broadcast link, just like GRE did.  Unfortunately we can't do that unilaterally because the routing layer behavior for those two subtypes is different -- different hello protocols and different data packet headers.  So we're stuck with the bad decision the original fools made.

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

I understand, and that makes sense.

>> DDCMP is en entirey different beast.  It provides that reliable data link, and it sits on top of an unreliable physical layer.  It handles packet loss mostly because it handles bit error, which causes packet CRC error and is handled by timeout and retransmit ("ARQ").
> 
> 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.)

Sequence numbers also detect duplicates and reordered packets, with limits.  The design of the sequence number space doesn't account for reordering, since wires don't do that.  But if the max queue size is well below 255, and if the packet lifetime in the connecting network is less than the time it takes the endpoints to send 256 packets, then reordering will be detected.  This is actually the same constraint as applies to any sequence numbered protocol (like TCP or NSP) but DDCMP has comparatively small sequence numbers.  Not as small as Bisync, though.  :-)

>>> ...
>>> 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.
>> No.  It's certainly ok to use DDCMP over TCP -- except that it has to deal with the oddity of doing both connect and listen concurrently.  But UDP works fine.
> 
> 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.

Actually, the SIMH implementation, and therefore the PyDECnet one, does not do so.  That's different from Multinet, which comes with a connect vs. listen setting.  In the case of DDCMP, both endpoints connect and both listen.  If a connection is made the other pending one is abandoned.  If both connections are made at essentially the same time, things get a bit messy, which is why I don't really like this technique.

	paul