clarify the meaning of "application-limited" #139
Conversation
Clarify the meaning of "application-limited" to explicitly mention that this can include slow sender applicaitons or slow receiver applications. Matt Olson notes in Issue NTAP#137: It seems like usually "app-limited" refers only to the local app, but if the peer's receive window limits the connection's send rate then we have the same problem where CWnd can grow arbitrarily. So, is "app-limited" supposed to also refer to the peer's receive window? If so, then this should probably be spelled out. So we should be explicit that application-limited can refer to sender or receiver apps that are slower than what cwnd allows. We should particularly clarify this because the text on this topic in 7661 is buggy, when it says: "application-limited period" for the time when the sender sends less than is allowed by the congestion or receiver windows. This RFC 7661 text is buggy because if the receiver window is smaller than the congestion window, and the sender sends an amount equal to the receiver window, then the flow is application-limited (it is limited by the receiver and receiver advertised window instead of cwnd).
Sure, added a change log entry in a separate commit in the same pull request: |
draft-ietf-tcpm-rfc8312bis.md
Outdated
| less than is allowed by the congestion window. | ||
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
This seems to be the last open review comment. I will merge and publish a new rev once the PR shows no requested changes.
There was a problem hiding this comment.
Thanks, Vidhi and Lars. This morning's patch should reflect Vidhi's suggestion now:
https://github.com/NTAP/rfc8312bis/pull/139/files
| @@ -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 | |||
There was a problem hiding this comment.
"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)?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
I'd be alright with leaving this text as Neal has written it, which is still vague but better than the existing text.
Co-authored-by: Vidhi Goel <goel.vidhi07@gmail.com>
|
Could we finalize this PR? |
From @larseggert and @goelvidhi. Co-authored-by: Lars Eggert <lars@eggert.org>
The latest patch caused a lint error: draft-ietf-tcpm-rfc8312bis.md:1017:81 MD013/line-length Line length [Expected: 80; Actual: 99] Fixed by wrapping: "and thus sends less data than what is allowed by the sender's congestion window."
Clarify the meaning of "application-limited" to explicitly
mention that this can include slow sender applicaitons
or slow receiver applications.
Matt Olson notes in Issue #137:
It seems like usually "app-limited" refers only to the local app,
but if the peer's receive window limits the connection's send
rate then we have the same problem where CWnd can grow
arbitrarily. So, is "app-limited" supposed to also refer to the peer's
receive window? If so, then this should probably be spelled out.
So we should be explicit that application-limited can refer to sender
or receiver apps that are slower than what cwnd allows.
We should particularly clarify this because the text on this topic
in 7661 is buggy, when it says:
"application-limited period" for the time when the sender sends less
than is allowed by the congestion or receiver windows.
This RFC 7661 text is buggy because if the receiver window is
smaller than the congestion window, and the sender sends
an amount equal to the receiver window, then the flow is
application-limited (it is limited by the receiver and receiver
advertised window instead of cwnd).