[HECnet] HECnet routing costs

[Paul Koning]

> On Jul 28, 2019, at 9:31 AM, Johnny Billquist <bqt at softjar.se> wrote:
> 
> People, I have written a page about DECnet costs and HECnet costs, which I would recommend that anyone interested read through. It contains a bit of elaboration on how DECnet does routing, and gives some suggestions on how costs could be set on HECnet to make it perform better.
> 
> I have noticed over the years that sometimes we do get really silly routing decisions just because of how people set, or do not set costs. The page I've written is by no means perfect, nor are the suggestions in there. But feel free to come with feedback, or ignore it. But I am going to try and use this myself more properly from now on, and that means that if others don't, you probably are going to get more traffic through your nodes. Traffic that probably do not make sense that it passes through you, but I just feel that I prefer to try and make it work right from my point of view, and then just at least tell people how I worked my numbers out. If someone have a different idea, I'm open to changing my settings, but I will not try and do optimizations to achieve:
> a) Same paths for packets in both directions - DECnet explicitly does not do this.
> b) Specifically penalize one type of interface because of any subjective preference about that type of interface in general.
> 
> Oh - and the link to my writeup: http://mim.update.uu.se/costs.htm

That sounds like a good proposal.

The comment about routes not necessarily matching in the other direction: that's potentially true for any hop by hop routed protocol.  It's pretty much unavoidable if you have hierarchical routing because the information available isn't the same in the two directions.  It also doesn't matter.  If the cost assignments are reasonable, then the routes will be, and asymmetry is utterly irrelevant.

The proposal doesn't address links that don't carry IP traffic, such as actual DEC hardware -- DMC-11 links, or async DDCMP, etc.  For those I suggest adding in the delay for a standard large packet (570 bytes) given the performance of the nodes and the link speed.  For example, a 9600 baud DDCMP link would have a latency for that packet size of just under 600 ms, so its cost would be 30 by your formula.  That's not actually legal so the max permitted cost would apply (25).  For fast links like coax DMC-11 or DEUNA the wire delay is a few ms or better, so the latency contribution would be 1 by your formula; given the machine performance a slight increase might be justified.

That makes me wonder: you mention adding in 2 "for the node".  Maybe that should be a bit larger for slow nodes.

Than again, the best answer is to do something that seems reasonable and observe what happens; fine tuning is best done with empirical data.

	paul