You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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)
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
The text was updated successfully, but these errors were encountered: