kGranularity and max_ack_delay possibly should be added after exponential backoff

[ianswett]

Right now, exponential backoff occurs last. But it's reasonable to consider adding/maxing them at the end after exponential backoff.

On the one hand, the current pseudocode provides true exponential backoff. On the other hand, it might be overly conservative in some cases. This only applies on subsequent PTOs, so maybe this is an academic question.

I'm opening this in the interest in discussing design issues on issues and not on PRs, but I'm also fine with it being closed as not being important and/or needing more information.

This came up in #2365

[nibanks]

I also agree kGranularity and max_ack_delay should be applied after the exponential; especially kGranularity which is only there to account for clocks/timers that have a minimum time you can set. No need to compound that inaccuracy inside the exponent.

[ianswett]

In an effort to align with TCP, kGranularity is now considered here:
PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay

In TCP, is the exponential backoff done before kGranularity is considered?

[pravb]

TCP does not use kGranularity because minRTO already accounts for it indirectly i.e. minRTO values have never been allowed to be set lower than the timer granularity. But yes in TCP minRTO is included in the exponential backoff so it makes sense to keep the equation as is. I think we are effectively using kGranularity as minRTO here.

In any case I think max_ack_delay is going to be the dominant value here in practice unless delayed ACKs are turned off. I wonder if another option is this:
PTO = smoothed_rtt + max(4*rttvar) + max(max_ack_delay, kGranularity)

[ianswett]

As discussed in Prague, the feeling is the current formula is safe, correct, and follows RFC6298.

This formula was recently adjusted as a result of #2472