[HECnet] HECnet routing costs

[Paul Koning]

> On Jul 29, 2019, at 8:38 PM, Johnny Billquist <bqt at softjar.se> wrote:
> 
> On 2019-07-30 01:49, Paul Koning wrote:
>>> ...
>> 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.
> 
> It makes a lot of sense to add a little extra, or else you into a silly race condition with a single lost or corrupted packet. Will the next one manage to come in before or after the listen timer expires... With a few extra seconds, you create a window making it much more reliable...

True, but as I said, one PtP links there isn't supposed to be packet loss.  The x2 is there to handle delays caused by packet drops recovered at the data link layer.

For Ethernet, occasional packet drops are expected; the theory is that 2 in a row are quite unlikely.

>> ...
>> 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.
> 
> John, as well as your comments, jogged my memory a little, and I obviously was confusing the retransmission timeouts with the hello and listen timers here.
> 
> Funny thing, though. In RSX, the delay weight is 2, and delay factor is 32. Assuming that's with a fraction, it would imply 3.2. So defaults are somewhat the other way around, in RSX at least.

The delay factor is in units of 1/16th (except in PyDECnet where you just give the float value).  So 32 means 32/16 or 2.0 which is the default given in the spec.

	paul