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

Excess ack_delay could be non-compiance #4218

Merged
merged 5 commits into from Oct 15, 2020
Merged
Changes from 1 commit
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
4 changes: 2 additions & 2 deletions draft-ietf-quic-recovery.md
Expand Up @@ -353,7 +353,7 @@ samples, and rttvar is the variation in the RTT samples, estimated using a
mean variation.

The calculation of smoothed_rtt uses RTT samples after adjusting them for
acknowledgement delays. Excess delays are computed using the ACK Delay field of
acknowledgement delays. These delays are computed using the ACK Delay field of
the ACK frame as described in Section 19.3 of {{QUIC-TRANSPORT}}.

The peer might report acknowledgement delays that are larger than the peer's
Expand All @@ -374,7 +374,7 @@ min_rtt.
After the handshake is confirmed, any acknowledgement delays reported by the
peer that are greater than the peer's max_ack_delay are attributed to
unintentional but potentially repeating delays, such as scheduler latency at the
peer or loss of previous acknowledgements. These delays could also be due to
peer or loss of previous acknowledgements. Excess delays could also be due to
a non-compliant implementaton. Therefore, these extra delays are
considered effectively part of path delay and incorporated into the RTT
estimate.
Expand Down