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

Be clearer about persistent congestion #4429

Merged
merged 2 commits into from Dec 8, 2020
Merged
Changes from all commits
Commits
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
6 changes: 3 additions & 3 deletions draft-ietf-quic-recovery.md
Expand Up @@ -995,15 +995,15 @@ congestion without depending on PTO expiration.
### Establishing Persistent Congestion

A sender establishes persistent congestion after the receipt of an
acknowledgement if at least two ack-eliciting packets are declared lost, and:
acknowledgement if two packets that are ack-eliciting are declared lost, and:

* all packets, across all packet number spaces, sent between the send times of
two ack-eliciting packets are declared lost;
these two packets are declared lost;
Copy link
Contributor

Choose a reason for hiding this comment

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

I know we keep disagreeing about this, but I think paralellism is important. Above, they're called "two ack-eliciting packets" and below we drop 'ack-eliciting', which I find confusing.

If you don't want to restate ack-eliciting, then I'd suggest "if two packets that are ack-eliciting are declared lost,"...


* the duration between the send times of these two packets exceeds the
persistent congestion duration ({{pc-duration}}); and
Copy link
Member

Choose a reason for hiding this comment

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

down in the third bullet, maybe s/both packets/these two packets/


* a prior RTT sample existed when both packets were sent.
* a prior RTT sample existed when these two packets were sent.

These two packets MUST be ack-eliciting, since a receiver is required to
acknowledge only ack-eliciting packets within its maximum ack delay; see Section
Expand Down