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

Jump to bottom

Reference RFC7661 for application limited #2605

Merged
merged 7 commits into from Apr 17, 2019
Merged

Reference RFC7661 for application limited #2605

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
c06161f
Reference RFC7661 for application limited
ianswett Apr 10, 2019
77de41b
Update draft-ietf-quic-recovery.md
ianswett Apr 11, 2019
b3a0ba4
Update draft-ietf-quic-recovery.md
janaiyengar Apr 15, 2019
a7f5cb5
Update draft-ietf-quic-recovery.md
janaiyengar Apr 15, 2019
6eb6813
Update draft-ietf-quic-recovery.md
janaiyengar Apr 15, 2019
17ca3a4
Update draft-ietf-quic-recovery.md
ianswett Apr 15, 2019
4b78a46
Update draft-ietf-quic-recovery.md
ianswett Apr 15, 2019
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
28 changes: 11 additions & 17 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -742,25 +742,13 @@ As an example of a well-known and publicly available implementation of a flow
pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
in Linux (3.11 onwards).


## Sending data after an idle period

A sender becomes idle if it ceases to send data and has no bytes in flight. A
sender's congestion window MUST NOT increase while it is idle.

When sending data after becoming idle, a sender MUST reset its congestion window
to the initial congestion window (see Section 4.1 of {{?RFC5681}}), unless it
paces the sending of packets. A sender MAY retain its congestion window if it
paces the sending of any packets in excess of the initial congestion window.

A sender MAY implement alternate mechanisms to update its congestion window
after idle periods, such as those proposed for TCP in {{?RFC7661}}.

## Application Limited Sending
ianswett marked this conversation as resolved.
Show resolved Hide resolved

The congestion window should not be increased in slow start or congestion
avoidance when it is not sufficiently 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
Copy link
Contributor

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.

Copy link
Contributor Author

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.

SHOULD NOT be increased in slow start or congestion avoidance when it is not
sufficiently utilized. The congestion window could be under-utilized due to
insufficient application data or flow control credit.
ianswett marked this conversation as resolved.
Show resolved Hide resolved

A sender MAY use the pipeACK method described in section 4.3 of {{?RFC7661}}
to determine if the congestion window is sufficiently utilized.
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 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?

Expand All @@ -770,6 +758,12 @@ and not fully utilize the congestion window due to this delay. A sender
should not consider itself application limited if it would have fully
utilized the congestion window without pacing delay.

Sending more than intial window into the network at once may cause losses.
ianswett marked this conversation as resolved.
Show resolved Hide resolved
Implemementations SHOULD use pacing, ACK-clocking, a reduction in CWND and/or
ianswett marked this conversation as resolved.
Show resolved Hide resolved
timers to minimize bursts.

A sender MAY implement alternate mechanisms to update its congestion window
after idle periods, such as those proposed for TCP in {{?RFC7661}}.
ianswett marked this conversation as resolved.
Show resolved Hide resolved


# Security Considerations
Expand Down