30 Jul
2019
30 Jul
'19
2:46 a.m.
On Jul 29, 2019, at 8:38 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2019-07-30 01:49, Paul Koning wrote:
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.
...
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. ...
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.