[HECnet] Another sillyness. More information in the nodename database on MIM.

[Paul_Koning at Dell.com]

On May 16, 2013, at 6:15 PM, Johnny Billquist wrote:

On 2013-05-16 23:12, Paul_Koning at Dell.com wrote:

...
The routing part looks pretty good right now.   I don't have it active all the time yet, but I hooked it into Multinet and it appeared to be stable.   The main issue is that point to point DECnet over UDP is architecturally invalid; the initialization state machine isn't designed for that.   The result is that it takes a while for both sides to agree that the circuit is "Up".   I've been thinking of workaround for the misbehavior.   A cleaner solution is to run Multinet over TCP, which appears to exist -- if someone can figure out how to do that and what the packet formats look like for that case, I'll implement it.   Alternatively, the SIMH DMC11 protocol works very well, it would clearly be a superior solution for Hecnet.

I haven't looked enough to really make sensible comments, but in which way is point-to-point over UDP invalid? I would have thought that wouldn't be any different than if you had an ethernet segment with just two nodes on it (I'm assuming Multinet UDP tunnels act like ethernet, but I might be wrong on that one as well...)

No, the Multinet UDP tunnel uses the point to point datalink dependent sublayer of DECnet.   

Quoting from the Phase IV routing spec:

The required Data Link Layer guarantees for point-to-point links are:

        1.   Provision that both source   and   destination   nodes   complete
                start-up before message exchange can occur

        2.   Detection of remote start-up

        3.   Provision that no old messages be received after start-up   is
                complete

        4.   Masking of transient errors in order to prevent   packet   data
                corruption

        5.   Provision for not duplicating or corrupting packets

        6.   Packet sequentiality ensuring that,   if   a   packet   has   been
                received, all previously sent packets have been received

        7.   Reporting of failures and degraded circuit conditions


The required Data Link Layer guarantees for Ethernets are:

        1.   Provision for not corrupting packets

        2.   Packet sequentiality ensuring that,   if   a   packet   has   been
                received,   no   previously   sent   packet   will be subsequently
                received

So the expectations on the datalink layer are dramatically different.   And as a result, the algorithms in the routing layer are, also.   In particular, the circuit initialization state machine in the routing layer (chapter 7 of the spec) relies quite strongly on many of the stated requirements.   

The DMC emulation in SIMH implements all of those requirements, which is why it works very well indeed.   

On the other hand, UDP implements requirements 4 and 5, but none of the rest.   The lack of properties 1, 2, and 3 completely invalidates the circuit initialization state machine (its design is very much dependent on those properties being satisfied).   I can see the proof of this all the time if I trace what happens on a Multinet link.   It keeps cycling because one end or the other receives an init message while in run state.   That happens when the other end restarts, but since #2 is missing, the state machine sees that as an unexpected message in run state rather than a preceding datalink restart when that message is expected to be seen next.   With enough retries (and, perhaps, some luck) the two ends eventually come to the right conclusion, but it takes a lot of cycling.

I think I can make some nonstandard changes to the state machine to work around this issue.   After all, it's obvious enough that one can design a datalink dependent sublayer for UDP -- it's just that there isn't one in the DECnet Phase IV architecture.   And whoever contrapted the UDP based Multilink tunnel either didn't care about that or didn't understand what he was doing wrong.

	paul