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