[HECnet] Multinet peerings...?

[Johnny Billquist]

On 2016-01-14 21:02, Peter Lothberg wrote:
>> The values are somewhat arbitrary; it doesn't really matter what
>> scheme you use but if you are inconsistent the routing may be
>> surprising.
>>
>> The routing spec has a suggested algorithm (100,000/line speed)
>> which may have made sense in the old days but for modern networks
>> isn't terribly useful.
>> 	paul
>
> What I wanted to get to was a scenario where traffic was symetric
> between two nodes, eg, use the same links from a-b as b-a, it makes it
> much easier to understand what's wrong when things behave funny...
>
> Maybe performance is not the most important factor in Hecnet.?
>
> -P
>
> Ps: In parts of the big internet, the metric for a link reflects it's
>      delay (remember speed of light in glass is not that great...).

What I realized when I was working with Steve this Sunday was that in 
many cases, the biggest performance hit comes if you have several area 
routers and use the bridge. For most other purposes, as long as you stay 
consistent, you should be good. The bridge is actually not a performance 
problem itself, as such.

However, anyone talking to MIM will suffer, and will continue to suffer, 
as long as they use the bridge.

Bridge performance should be equal to the Multinet links in general. 
And, of course, if you are communicating between nodes in the same area, 
the bridge should even be better than the Multinet links.

The situation where you loose is when you go from one area to another, 
and you have several area routers on the same ethernet segment you 
yourself are on. In this situation, DECnet will pick the highest 
numbered node in the remote area, and use that as the next hop to the 
area. Now, in HECnet, area 1 have three area routers. MIM, PONDUS and 
JOCKE. While most people would like to talk to MIM, if they talk with 
area 1, they will always be routed through JOCKE or PONDUS, since those 
two machines have higher numbers.
In the past, only PONDUS was the additional area router, and PONDUS is a 
real PDP-11/93. Not the fastest machine around. In addition, PONDUS and 
JOCKE are located in Switzerland, while MIM is in Sweden.

So, anyone outside of area 1 trying to talk to MIM over the bridge would 
send the packets to PONDUS, in Switzerland, and PONDUS would then send 
the packets back out on the same bridge to get to MIM. Responses back 
would go direct, as MIM would, on its own, know where to route the 
packets returned.

But this is pretty suboptimal. And there isn't much we can do about it. 
That is the way DECnet works. It would be wonderful to be able to point 
to MIM as being the primary area router for area 1, but DECnet only have 
this concept for intra-area deignated routers on an ethernet. That's 
where the router priority is used. But for areas, no such thing exists. 
Obviously, in the old days, you would not expect people on the same 
ethernet segment to actually be in different areas, so it was probably 
never thought much about. But that is exactly the scenario the bridge 
creates.

And, obviously, the solution is to actually have ptp-links between areas 
instead. And I'm working on it. However, I have hit some obscure bug in 
my code related to multiprocessor RSX internals, which I'm still trying 
to figure out. Once that is solved, I'll start actually getting these 
links running on mim, and people in other areas can optionally stop 
using the bridge to area 1, which will improve life.

As for cost tweaking for other areas (areas without multiple area 
routers that is), I do not believe that tweaking the costs to favor 
Multinet links will improve life. But I'm interested to hear theories 
that claims otherwise, and we can try figuring out if they make sense.

	Johnny