[HECnet] Old protocols in new ones

[Paul Koning]

> On Mar 28, 2021, at 4:40 PM, Johnny Billquist <bqt at softjar.se> wrote:
> 
> 
> 
> On 2021-03-28 22:10, Paul Koning wrote:
>>> 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.
> 
> 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.

Sorry, I wasn't clear what I meant.  The comment was not directed at the list you gave but a general observation about data link layer protocols.

>> ...
> 
>> 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.
> 
> Technically, TCP should work just fine. But yes, Multinet even have some funny specific behavior making even TCP a bit tricky.

No, technically Multinet TCP does NOT work fine.  The issue is that Multinet, whether over TCP or over UDP, fails several of the requirements imposed on point to point datalinks by the DECnet routing spec.  In particular, it fails the requirement of "restart notification".  In the TCP case, it can be hacked to make it work most of the time, but architecturally speaking it's flat out wrong.

The issue is that there is more to a point to point datalink that merely delivering a packet stream from point A to point B.  That's the main job, of course, but that by itself is not sufficient in the DECnet architecture.

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

There are two ways to make a "data link similar to Multinet that actually works".  One is to run it over TCP and include some mechanism to deliver the "restart detection" requirement.  The other is to run it over either TCP or UDP and call it a broadcast link, i.e., a GRE lookalike.

The former would be vaguely like the old "DDCMP emulation" in SIMH 2.9 that I once had in PyDECnet but removed -- the one that sends DMC payloads over TCP.  That might be worth doing if people were interested in deploying it.  I could dust of that old code to serve as the template to follow.

The latter would be like GRE, but it wouldn't really do anything that GRE doesn't do just as well so there wouldn't be a whole lot of point in it.

> ...
>> 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.
> 
> Yeah. I wouldn't do it that way. That is ugly.
> Better to designate one as the connector and the other as the listener.

True, and if it weren't for the fact that SIMH set the rule differently that's what I would have done.

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

X.25 requires it because it has what many of us consider a protocol design error, 2-way connection handshake.  DDCMP (and others) uses a 3-way handshake and deals just fine with simultaneous startup.  The only reason the SIMH scheme has a problem is that you don't want to have two connections remain open.  But you can see that DDCMP doesn't mind from the fact that over UDP it has no problem with simultaneous startup.  The rules of the startup state machine explicitly cover that case.

	paul