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

Limit ack_delay by max_ack_delay #2099

Merged
merged 4 commits into from Dec 7, 2018
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
40 changes: 23 additions & 17 deletions draft-ietf-quic-recovery.md
Expand Up @@ -265,34 +265,38 @@ all subsequent ACK frames containing them could be lost. In this case, the
loss recovery algorithm may cause spurious retransmits, but the sender will
continue making forward progress.


# Loss Detection

QUIC senders use both ack information and timeouts to detect lost packets, and
this section provides a description of these algorithms. Estimating the network
round-trip time (RTT) is critical to these algorithms and is described first.

If a packet is lost, the QUIC transport needs to recover from that loss, such
as by retransmitting the data, sending an updated frame, or abandoning the
frame. For more information, see Section 13.2 of {{QUIC-TRANSPORT}}.

## Computing the RTT estimate
# Computing the RTT estimate

RTT is calculated when an ACK frame arrives by computing the difference between
the current time and the time the largest acked packet was sent. An RTT sample
MUST NOT be taken for a packet that is not newly acknowledged or not
ack-eliciting. When RTT is calculated, the ack delay field from the ACK frame
SHOULD be subtracted from the RTT as long as the result is larger than the
Min RTT. If the result is smaller than the min_rtt, the RTT should be used, but
the ack delay field should be ignored.
ack-eliciting.

When RTT is calculated, the ack delay field from the ACK frame SHOULD be limited
to the max_ack_delay specified by the peer. Limiting ack_delay to max_ack_delay
ensures a peer specifying an extremely small max_ack_delay doesn't cause more
spurious timeouts than a peer that correctly specifies max_ack_delay. It SHOULD
be subtracted from the RTT as long as the result is larger than the min_rtt.
If the result is smaller than the min_rtt, the RTT should be used, but the
ack delay field should be ignored.
Copy link
Contributor

Choose a reason for hiding this comment

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

I wouldn't add this in before we resolve #2060.

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 is just moving text from below, FYI

Copy link
Contributor

Choose a reason for hiding this comment

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

facepalm Of course.


Like TCP, QUIC calculates both smoothed RTT and RTT variance similar to those
specified in {{?RFC6298}}.

Min RTT is the minimum RTT measured over the connection, prior to adjusting by
min_rtt is the minimum RTT measured over the connection, prior to adjusting by
ack delay. Ignoring ack delay for min RTT prevents intentional or unintentional
underestimation of min RTT, which in turn prevents underestimating smoothed RTT.

# Loss Detection

QUIC senders use both ack information and timeouts to detect lost packets, and
this section provides a description of these algorithms. Estimating the network
round-trip time (RTT) is critical to these algorithms and is described first.

If a packet is lost, the QUIC transport needs to recover from that loss, such
as by retransmitting the data, sending an updated frame, or abandoning the
frame. For more information, see Section 13.2 of {{QUIC-TRANSPORT}}.

## Ack-based Detection

Ack-based loss detection implements the spirit of TCP's Fast Retransmit
Expand Down Expand Up @@ -738,6 +742,8 @@ Pseudocode for OnAckReceived and UpdateRtt follow:
UpdateRtt(latest_rtt, ack_delay):
// min_rtt ignores ack delay.
min_rtt = min(min_rtt, latest_rtt)
// Limit ack_delay by max_ack_delay
ack_delay = min(ack_delay, max_ack_delay)
// Adjust for ack delay if it's plausible.
if (latest_rtt - min_rtt > ack_delay):
latest_rtt -= ack_delay
Expand Down