[HECnet] HECnet routing costs

[Paul Koning]

> 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.

That's the phase IV definition.  The rule is just a simple integer multiple of the hello timer at the other end.  There is no "plus jiffy" in the spec, but using a larger than specified listen timer (within reason) is not a problem.

The T3 multiplier is larger for Ethernet because that's a datagram datalink, so it allows for the possibility of hello messages being dropped.  On point to point links that doesn't happen (not on real ones, that is).

For similar reasons, there is a BCT1 and a T1 timer, regulating background transmission of routing messages.  BCT1 should be similar in value to BCT3, because it serves the same purpose.  T1 exists to make the routing protocol self-stabilizing: if a router somehow gets confused about the routes, within T1 that will be cured.  That "should never happen" so a long timeout, 600 to 900 seconds, is typically used.  Multinet, especially over UDP,  should be treated as an Ethernet for this purpose and its T1 should be set to 15-30 seconds like the hello timer.

On Delay Factor and Delay Weight: delay weight is the weighting factor for the weighted average estimation of the round trip delay to the destination that NSP does.  The larger the value, the more fluctuations of round trip delay are filtered out and the slower NSP adjusts to persistent changes in the delay.  The suggested default is 3.

Delay factor is the multiplier applies to the estimate to get the ACK timeout  It's a number with a fraction for some reason.  The default is 2, which is a good number if round trip delays are pretty consistent.  If they vary significantly, you might want a larger value to reduce the number of retransmits that occur when an ACK is only delayed.  But of course, the larger this value, the longer it takes to do a retransmit that's actually needed because of real packet loss.

	paul