Skip to content
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

Discuss Application-Limited Sending #1637

Merged
merged 13 commits into from Jan 29, 2019
7 changes: 4 additions & 3 deletions draft-ietf-quic-recovery.md
Expand Up @@ -1004,9 +1004,10 @@ under-utilized due to insufficient application data to send or flow control
limits.
ianswett marked this conversation as resolved.
Show resolved Hide resolved

When the sender is pacing (see {{pacing}}) packets, the sender may be unable
to use the full congestion window for a period of time after receiving an
ACK, due to pacing. In this case, the sender should not consider themselves
application limited and should allow the congestion window to increase.
to use the full congestion window for a period of time after receiving
acknowledgements, due to pacing. In this case, the sender should not consider
themselves application limited and should allow the congestion window to
increase.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested rephrasing: "A sender that uses pacing (see {{pacing}}) might delay sending of packets and might not fully utilize the congestion window due to this delay. A sender should not consider itself application limited if it might have utilized the entire congestion window without pacing delay."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Accepted with minor tweaks.


## Discarding Packet Number Space State

Expand Down