[HECnet] HECnet routing costs

[Johnny Billquist]

On 2019-07-28 22:37, John Forecast wrote:
> 
> 
>> On Jul 28, 2019, at 4:03 PM, John Forecast <john at forecast.name> wrote:
>>
>>
>>
>>> On Jul 28, 2019, at 12:00 PM, Johnny Billquist <bqt at softjar.se> wrote:
>>>
>>> I should correct myself. The exact formula for how the listen timer is set, based on the remote hello timer, is a bit more complex. I remember that I saw it described somewhere, but cannot remember the details right now.
>>> So my "two times hello plus some jiffy" is rather incorrect in fact. It turns out to that for some values in the end, but it varies because of other parameters as well.
>>>
>> It’s defined in the routing spec where it discusses routing parameters (section 4.1 of the 2.0.0 spec). it’s a simple multiplier of the other end’s hello timer, (T3MULT for point-to-point circuits and BCT3MULT for broadcast circuits) so the listener timer (T4) will be set to “hello timer * xT3MULT” depending of the circuit type. For point-to-point circuits, any incoming traffic will reset the listener timer.
>>
> I missed out one important part, xT3MULT are defined as architectural constants so you can’t change their value, T3MULT = 2 and BCT3MULT = 3.

I seem to remember also reading something about a relationship to the 
executor delay weight and delay factor, but I might be mixing up several 
things here, and I'm too lazy to actually go and try to find the 
information. :-)

However, a couple of observations under RSX:
hello timer=15 on ethernet: listen timer=56.
hello timer=10 on ethernet: listen timer=40
hello timer=300 on ddcmp: listen timer=608

So, from that short sample, it would seem that a 3x for ethernet, and 2x 
for ddcmp is the basis, but then there is a little bit more added, which 
is not totally clear how it is worked out.

   Johnny

> 
>    John.
> 
>>   John.
>>
>>> But the basic principle is correct. The listen timer is based on the hello timer, and is used to determine if a circuit is down. And the hello timer is the interval at which hello packets are sent on the circuit.
>>>
>>> And changing the hello timer causes less traffic, and longer time before a circuit down is detected (unless some other mechanism allows detection of a circuit down earlier).
>>>
>>> Johnny
>>>
>>> On 2019-07-28 17:52, Johnny Billquist wrote:
>>>> The hello timer is essentially how long between the node sends out the hello messages on a circuit. This in turn, is used to detect when a circuit goes down.
>>>> The listen timer is on a per node basis for adjacent nodes, and is set to two times the hello time, plus a few seconds. So the detection of a circuit going down is when the listen time expires.
>>>> You cannot directly set the listen timer, but you can choose your own hello timers, and having a longer time means the other end will take longer before it detects a circuit going down.
>>>> All that said, I usually have long times, since I do not feel really quick detection of a circuit down is that important, but I don't mind reducing the traffic a load a little.
>>>> Other than that, everyone should feel free to make whatever choice they feel most appropriate for their expectations.
>>>>   Johnny
>>>> On 2019-07-28 16:41, Mark Matlock wrote:
>>>>> Johnny,
>>>>>     I have one question I’ve been meaning to ask about hello timers and listen timers. The default seems to to be 15 seconds hello and 40 seconds listen. But on MIM I have seen some other combinations like Hello 300 secs but the Listen varies from 608 to the default 40 (at least on IP-0-10)
>>>>> All the values seem to work ok, but on my 30.1 node which is a real PDP-11, I’d like to use something closer to 300 and 600+ to reduce load and unneeded up and down messages due to my flakey ISP’s internet.
>>>>>
>>>>> What are your thoughts on this topic?
>>>>>
>>>>> Thanks!
>>>>> Mark
>>>>>
>>>>>> On Jul 28, 2019, at 8: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
>>>>>>
>>>>>>   Johnny
>>>>>>
>>>>>> -- 
>>>>>> Johnny Billquist                  || "I'm on a bus
>>>>>>                                   ||  on a psychedelic trip
>>>>>> email: bqt at softjar.se             ||  Reading murder books
>>>>>> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>>>>>
>>>
>>> -- 
>>> Johnny Billquist                  || "I'm on a bus
>>>                                  ||  on a psychedelic trip
>>> email: bqt at softjar.se             ||  Reading murder books
>>> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>>
> 

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol