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.

Sign up for GitHub

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

Remove mention of pipeACK #4190

Merged
merged 5 commits into from Oct 13, 2020
Merged

Remove mention of pipeACK #4190

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
d9ac648
Clarify that pipeACK is an example
ianswett Oct 12, 2020
e832f5d
Update draft-ietf-quic-recovery.md
ianswett Oct 12, 2020
7bc0c7f
Update draft-ietf-quic-recovery.md
ianswett Oct 12, 2020
606b7d2
Remove paragraph per mirja's suggestion
ianswett Oct 12, 2020
f61b2d0
Change references to 3168 to be normative
ianswett Oct 12, 2020
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
2 changes: 1 addition & 1 deletion draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -1087,7 +1087,7 @@ congestion avoidance. This can happen due to insufficient application data
or flow control limits.

A sender can use a variety of mechnaisms to determine if the congestion window
ianswett marked this conversation as resolved.
Show resolved Hide resolved
is sufficiently utuilized. For example, the pipeACK method described in
is sufficiently utilized. For example, the pipeACK method described in
Section 4.3 of {{?RFC7661}}.
Copy link
Contributor

Choose a reason for hiding this comment

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

I would actually rephrase this part completely (or maybe just remove it entirely as there is another reference two paragraphs down). RFC7661 mainly uses the term "application-limited", however, it does not really propose a mechanism to exactly detect that a connection is application-limited, but rather proposes additional mechanism to even decrease the congestion window when no validated. It further says that the cwnd window MUST NOT be increase when not cwnd-limited and that cwnd-limitation is detected based on FlightSize (or other mechanism, see also section 4.5.3 of RFC7661) as also described in the previous paragraph in the recovery draft:

A sender that is not cwnd-limited MUST NOT increase the cwnd
         when ACK packets are received in this phase

So I don't think RFC7661 actually provides any different meachanism to detect if the cwnd is sufficiently utilised.

Please note also that RFC7661 actually says MUST NOT while the QUIC recovery draft has only a SHOULD NOT...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, I'll remove this paragraph.


A sender that paces packets (see {{pacing}}) might delay sending packets
Expand Down