Skip to content
This repository has been archived by the owner on Aug 28, 2023. It is now read-only.

clarify the meaning of "application-limited" #139

Merged
merged 7 commits into from Jan 26, 2022
Merged

clarify the meaning of "application-limited" #139

Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
d308319
clarify the meaning of "application-limited"
nealcardwell Jan 18, 2022
1c0f006
fix trailing space caught by markdown lint tool
nealcardwell Jan 18, 2022
ad37705
add a changelog entry at the request of larseggert
nealcardwell Jan 18, 2022
72d174d
fix typo
nealcardwell Jan 19, 2022
c1f8e58
tighten up: "less than is allowed" -> "less than what is allowed"
nealcardwell Jan 19, 2022
9727140
use "and thus sends less data than what is allowed by"
nealcardwell Jan 25, 2022
82d96ba
fix line length lint error from previous patch
nealcardwell Jan 25, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
15 changes: 11 additions & 4 deletions draft-ietf-tcpm-rfc8312bis.md
View file
Open in desktop
Expand Up @@ -486,8 +486,8 @@ cwnd &
{: artwork-align="center" }

The elapsed time *t* in {{eq1}} MUST NOT include periods during
which *cwnd* has not been updated due to an application limit (see
{{app-limited}}).
which *cwnd* has not been updated due application-limited behavior
nealcardwell marked this conversation as resolved.
Show resolved Hide resolved
(see {{app-limited}}).

Depending on the value of the current congestion window size *cwnd*,
CUBIC runs in three different regions:
Expand Down Expand Up @@ -1010,8 +1010,13 @@ This is not considered in the current CUBIC design.

## Behavior for Application-Limited Flows {#app-limited}

CUBIC does not increase its congestion window size if a flow is
currently limited by the application instead of the congestion window.
A flow is application-limited if it is currently sending
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"currently sending less than cwnd"- is this too general? A pacer or CPU bottleneck could also cause this to happen. Although, maybe it would also make sense to limit cwnd growth in those cases (since the point is that increasing the cwnd will not increase the send rate)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pacing the send rate doesn't mean you are sending less than cwnd (excluding app-limited), it just means that you are sending the cwnd paced within a duration (equal to RTT) instead of sending it all at once. As the cwnd growth is based on received ACKs, and ACKs themselves are dependent on sent data, the cwnd sort of grows somewhat paced too (unless the ACKs are coalesced).

I agree that "currently sending less than cwnd" is too generic and maybe we can add text about pacing etc to clarify this. But the rest of the text about cwnd growth looks fine.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm talking about particular instants in time when I talk about pacing- we will eventually send the whole window, but at the time when we are making a decision about whether to increase the CWnd, we may have deferred sending some of those packets until later in the round. I'm not allowed to look at the linux code, but it's my rough understanding that normally it goes ahead and posts the full CWnd of packets with appropriate "due times" for actually sending each packet, but that's only one possible implementation. TCP itself could also defer sending with a timer (which I think I heard has also been implemented in linux).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be alright with leaving this text as Neal has written it, which is still vague but better than the existing text.

less than is allowed by the congestion window.
nealcardwell marked this conversation as resolved.
Show resolved Hide resolved
This can happen if the flow is limited by either the
sender application or the receiver application (via the receiver
advertised window) instead of the sender's congestion window.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got a little confused when I first read instead of the sender's congestion window.
Should we rephrase it to, ... window) and thus sends less data than what is allowed by the sender's congestion window.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be the last open review comment. I will merge and publish a new rev once the PR shows no requested changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, Vidhi and Lars. This morning's patch should reflect Vidhi's suggestion now:
https://github.com/NTAP/rfc8312bis/pull/139/files

nealcardwell marked this conversation as resolved.
Show resolved Hide resolved

CUBIC does not increase its congestion window if a flow is application-limited.
{{win-inc}} requires that *t* in {{eq1}} does not include
application-limited periods, such as idle periods, otherwise
W<sub>cubic</sub>(*t*) might be very high after restarting from these
Expand Down Expand Up @@ -1084,6 +1089,8 @@ These individuals suggested improvements to this document:

## Since draft-ietf-tcpm-rfc8312bis-05

- Clarify meaning of "application-limited" in Section 5.8
([#137](https://github.com/NTAP/rfc8312bis/issues/137)
- Brief discussion of convergence in Section 5.6
([#96](https://github.com/NTAP/rfc8312bis/issues/96))
- Add more test results to Section 5 and update some references
Expand Down