-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reference RFC7661 for application limited #2605
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this -- I think it's the right direction. Some comments to try and herd this text some more.
draft-ietf-quic-recovery.md
Outdated
avoidance when it is not fully utilized. The congestion window could be | ||
under-utilized due to insufficient application data or flow control credit. | ||
A sender's congestion window MUST NOT increase when no packets are newly | ||
acknowledged, such as when the connection is idle. The congestion window |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a strange requirement, since the specified CC only increases on receiving ACKs. This was already written earlier in other words, and I realize now that it was a strange requirement then as well. I wonder if just removing this first sentence makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was written to specifically forbid the cubic bug, but I realize it's not even tight enough to do that, so I'll remove it.
insufficient application data or flow control credit. | ||
|
||
A sender MAY use the pipeACK method described in section 4.3 of {{?RFC7661}} | ||
to determine if the congestion window is sufficiently utilized. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how to read this. We are saying that the sender SHOULD NOT increase the cwnd if it's under-utilized, but we are not quite defining what under-utilized means and instead pointing to pipeACK for one way of defining it (for TCP). This doesn't seem great to me.
For the purpose of this PR, how about you leave it like this and open a new issue to summarize a definition of an under-utilized cwnd?
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, updated
I'll take this in, and open an issue for defining "under-utilized cwnd" |
* Recovery release notes for draft 20 * Update draft-ietf-quic-recovery.md Add #2605 to the notes. * Update draft-ietf-quic-recovery.md Co-Authored-By: ianswett <ianswett@users.noreply.github.com> * Update draft-ietf-quic-recovery.md Co-Authored-By: ianswett <ianswett@users.noreply.github.com> * Nit * undo nit
Combines the section on sending after idle and application limited because they share a lot in common.
Praveen, I think this is better, but tell me if you'd like to add/change something else?
Fixes #2554 and #2555