[Simh] VMS/VDE: Almost there

[Paul Koning]

> On Oct 9, 2015, at 9:38 AM, Johnny Billquist <bqt at softjar.se> wrote:
> 
>>> ...
>> 	Phase II use NSP v3.1 so that’s probably another indication that it’s a Phase I product.
> 
> John, maybe you can clear some things up for me.
> Looking at the Wikipedia article about DECnet, it claims that phase I was simply between two nodes. No larger than that. And in addition was RSX-11 only. And it was 1974.

It wouldn't be at all surprising if the information about Phase I were inaccurate given its undocumented status.

> Phase II says multiple implementations on different systems, and a max of 32 nodes. Also supposedly added task-to-task programming interfaces. And supposedly 1975.
> 
> 
> Now, looking at the DECNET/8 documentation, there is some discrepancy here.
> DECNET/8 supports up to 127 nodes. It only have point-to-point links, but it clearly have some idea of dealing with several hops to reach the destination. It also obviously have task-to-task programming interfaces, which looks very similar to what I know from phase IV.
> 
> Now, I'm happy to believe that Wikipedia is just plain wrong, but it would be interesting to hear if you can provide any more details to what phase I and phase II differed on, and where DECNET/8 would fit based on that.

I looked at the document you sent.  While it has some hints about the protocol in chapter 6, it doesn't come close to telling us what's necessary to build a compatible implementation.  DDCMP might be compatible; the bits of packet layout given on page 6-4 seem to match those of the later DDCMP specs.

NSP, on the other hand, clearly is not compatible.  Again, there are only hints of packet layouts -- only some of those are shown and their semantics not described.   It has an optional routing header just as Phase II does, but encoded differently.  And the message type field (MSGFLG, first byte of the NSP message header proper) looks somewhat like that of later versions of NSP but the encoding is substantially different.   The Connect message looks vaguely like a later Connect Initiate, but the details are quite different.  Based on what little I can see, the statement in the Phase II spec that Phase I was incompatible (implying "it's not feasible for a Phase II node to interoperate with a Phase I node") is indeed accurate.

The normal case of Phase II was that it allowed communication only between adjacent nodes.  A given node could have multiple interfaces, presumably connected to different neighbors, and it would use the destination address of a packet to choose the correct interface on which to communicate.  The same would, I assume, apply to Phase I.

Phase II had an optional routing header for something called "intercept" operation.  The DECnet/8 document describes the same sort of thing though the encoding is different.  I can't tell if DECnet/8 could actually supply routing headers; it does say clearly that it would not act on them.  Similarly, most Phase II implementations didn't handle routing headers either (would neither generate nor accept them).  The Phase II spec is not all that clear on how they are supposed to be generated or used, in fact.  I vaguely remember that TOPS-10 (or -20?) used them, with the front end processor acting as the forwarding node and the main CPU as endpoint. So communication would be two hops: PDP-10 to front end to other node.  While theoretically there might be more hops, in practice that didn't happen.  For one thing, Phase II NSP doesn't appreciate lost packets.

In Phase III all that changed, with a real routing protocol, clearly documented routing operation, and an NSP that would do retransmission to handle lost datagrams.

	paul