[HECnet] HECnet routing costs

[Johnny Billquist]

On 2019-07-30 02:46, Paul Koning wrote:
> 
> 
>> 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.

I know. But then you have Murphy. Packets can be lost at more levels 
than the link as well.

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

Yes. Which makes total sense. But the 3x hello plus some small amount 
makes it resilient against that too. You would have to loose 3 packets 
in a row for the adjacency to be considered lost.

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

Ah. Silly unit in this context, but I guess it makes some sort of sense. 
Nice computerized fraction, except that the timers in DECnet/RSX are 
actually in 0.1s resolution.

Oh well. It works reasonably well anyhow. With the exception of a couple 
of bugs DEC never saw because they never ran as fast PDP-11s as exist 
today. People should not try and use FAL between a really fast and a 
really slow RSX system over ethernet. A transfer of a large file will 
take hours. I should try and fix that bug at some point.

   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