Set slow start threshold more accurately on loss to be flightsize/2 instead of
cwnd/2 as recommended by RFC5681.
Details
- Reviewers
jtl - Group Reviewers
transport - Commits
- rS308180: Set slow start threshold more accurately on loss to be flightsize/2 instead of
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 5718 Build 6013: arc lint + arc unit
Event Timeline
This is a bug exposed by recent commit https://svnweb.freebsd.org/base?view=revision&revision=307901
Thus I'd appreciate any reviews soon.
@sbruno: is there any log as to why the revert happend?
I'm asking, because for a very long time, the following behavior would ensue:
While application limited, the session never sees any loss - and cwnd can grow all the way to the receiver window. While at the same time, only a fraction of that window is in active use (only so much data is outstanding, to match the appliction transmit rate).
Now, when a loss actually happens (e.g. the application starts sending at higher speeds, or the network conditions change), ssthresh = cwnd/2 - but cwnd can be significantly inflated at this time already. Thus it takes multiple rounds of multiplicative decrease (more losses than absolutely necessary) for ssthresh and cwnd to get pulled back to a more reasonable, value...
Using flightsize (or a properly calculated rfc6675 pipe) would address that scenario - and should limit the number of loss recovery episodes needed to arrive at a good new cwnd.
Now, D21798 addresses this particular problem differently (by no longer growing cwnd, when the session is application limited).
But it's conceivable that an application reduced its sending rate prior to the CC reaction - so while cwnd no longer grows "unbounded", it may still not be a good reflection of the current state of the network...
Just curious if this shouldn't be revived - but curious for the reasoning about the revert first.
I think we need @hiren for further details for this revert. I believe he asked me to undo this.