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

Add MaxAckDelay sub-section #1574

Merged
merged 3 commits into from Jul 25, 2018
Merged

Add MaxAckDelay sub-section #1574

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c6f901d
Add MaxAckDelay sub-section
ianswett Jul 17, 2018
eb68d7a
Update draft-ietf-quic-recovery.md
ianswett Jul 17, 2018
eec56e6
Update draft-ietf-quic-recovery.md
ianswett Jul 17, 2018
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
34 changes: 20 additions & 14 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -206,6 +206,19 @@ 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.

### Maximum Ack Delay

QUIC is able to explicitly model delay at the receiver via the ack delay
field in the ACK frame. Therefore, QUIC diverges from TCP by calculating a
MaxAckDelay dynamically, instead of assuming a constant delayed ack timeout
for all connections.

MaxAckDelay is the maximum ack delay supplied in an all incoming ACK frames.
MaxAckDelay excludes ack delays that aren't included in an RTT sample because
they're too large or the largest acked has already been acknowledged.
MaxAckDelay also excludes ack delays where the largest ack references an
Copy link
Contributor

Choose a reason for hiding this comment

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

You've used "largest ack" and "largest acked" here. Elsewhere in the document, you also use "largest acknowledged." Might be worth picking one and using it consistently?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

PR #1611 sent

ACK-only packet.
Copy link

Choose a reason for hiding this comment

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

Lgtm


## Ack-based Detection

Ack-based loss detection implements the spirit of TCP's Fast Retransmit
Expand Down Expand Up @@ -338,15 +351,10 @@ conditions:
* If RTO ({{rto}}) is earlier, schedule a TLP in its place. That is,
PTO SHOULD be scheduled for min(RTO, PTO).

MaxAckDelay is the maximum ack delay supplied in an incoming ACK frame.
MaxAckDelay excludes ack delays that aren't included in an RTT sample because
they're too large and excludes those which reference an ack-only packet.

QUIC diverges from TCP by calculating MaxAckDelay dynamically, instead of
assuming a constant delayed ack timeout for all connections. QUIC includes this
in all probe timeouts, because it assume the ack delay may come into play,
regardless of the number of packets outstanding. TCP's TLP assumes if at least
2 packets are outstanding, acks will not be delayed.
QUIC includes MaxAckDelay in all probe timeouts, because it assumes the ack
delay may come into play, regardless of the number of packets outstanding.
TCP's TLP assumes if at least 2 packets are outstanding, acks will not be
delayed.

A PTO value of at least 1.5*SRTT ensures that the ACK is overdue. The 1.5 is
based on {{?TLP}}, but implementations MAY experiment with other constants.
Expand Down Expand Up @@ -399,11 +407,9 @@ immediate change to congestion window or recovery state. An RTO timer expires
only when there's a prolonged period of network silence, which could be caused
by a change in the underlying network RTT.

QUIC also diverges from TCP by including MaxAckDelay in the RTO period. QUIC is
able to explicitly model delay at the receiver via the ack delay field in the
ACK frame. Since QUIC corrects for this delay in its SRTT and RTTVAR
computations, it is necessary to add this delay explicitly in the TLP and RTO
computation.
QUIC also diverges from TCP by including MaxAckDelay in the RTO period. Since
QUIC corrects for this delay in its SRTT and RTTVAR computations, it is
necessary to add this delay explicitly in the TLP and RTO computation.

When an acknowledgment is received for a packet sent on an RTO event, any
unacknowledged packets with lower packet numbers than those acknowledged MUST be
Expand Down