Improve detection of CC-limited state #573
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At the moment, a flow is considered CC limited (i.e., CWND in increased) when an acknowledgment is received and if either the CWND or the pacer restricts the flow from sending more.
The problem with this approach is that once all data is sent, newly received acks do not increase CWND, even if those acks were sent while the sender was sending at full speed. To paraphrase, if an idle connection goes into CC-limited for X round-trips then becomes idle again, only packets sent during X - 1 round-trips cause the increase of CWND.
During slow start, this behavior might lead to slower CWND growth than what is ideal.
This PR changes the approach; now, packets affect the congestion window if the acked packet was sent while
inflight >= 1/2 * CWND
, or if the packet was acked under the same condition. 1/2 of CWND is adopted for having fairness to RFC 7661, but also provides correct increase; i.e., if an idle connection goes into CC-limited for X round-trips then becomes idle again, all packets sent during that X round-trips will be considered as CC-limited.This is a follow-up PR of #452.