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

Merge Crypto timeout and PTO #2806

Merged
merged 23 commits into from Jul 16, 2019
Merged
Changes from 1 commit
Commits
Show all changes
23 commits
Select commit Hold shift + click to select a range
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
21 changes: 11 additions & 10 deletions draft-ietf-quic-recovery.md
Expand Up @@ -514,11 +514,12 @@ and larger thresholds increase loss detection delay.

## Probe Timeout {#pto}

A Probe Timeout (PTO) triggers a probe packet when ack-eliciting data is in
flight but an acknowledgement is not received within the expected period of
time. A PTO enables a connection to recover from loss of tail packets or acks.
The PTO algorithm used in QUIC implements the reliability functions of Tail Loss
Probe {{?TLP=I-D.dukkipati-tcpm-tcp-loss-probe}} {{?RACK}}, RTO {{?RFC5681}} and
A Probe Timeout (PTO) triggers sending one or two probe packets when
Copy link
Contributor

Choose a reason for hiding this comment

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

This is probably obvious but it doesn't seem to explicitly say what causes 1 vs 2 packet to be sent. Perhaps this is clear elsewhere? I wonder if it might make sense to say something like "two packets, if there is sufficient data available, and one otherwise". But maybe that's not really helpful.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's 1 or 2 because some impls only do 1 packet PTO(TLP). I could recommend two packets during the handshake, in order to speed handshake completion?

It actually should be datagrams, but I'm inclined to change that in a follow-up, rather that burying it in this change?

ack-eliciting packets are not acknowledged within the expected period of
time or the handshake has not been completed. A PTO enables a connection to
recover from loss of tail packets or acks. The PTO algorithm used in QUIC
implements the reliability functions of Tail Loss Probe
{{?TLP=I-D.dukkipati-tcpm-tcp-loss-probe}} {{?RACK}}, RTO {{?RFC5681}} and
F-RTO algorithms for TCP {{?RFC5682}}, and the timeout computation is based on
TCP's retransmission timeout period {{?RFC6298}}.

Expand Down Expand Up @@ -1191,14 +1192,14 @@ SetLossDetectionTimer():

// Don't arm timer if there are no ack-eliciting packets
// in flight and the handshake is complete.
if (!(endpoint is client without 1-RTT keys ||
has ack-eliciting packets in flight):
if (endpoint is client with 1-RTT keys ||
no ack-eliciting packets in flight):
loss_detection_timer.cancel()
return
// Initialize the timeout if there are no RTT measurements

// Use a default timeout if ther are no RTT measurements
if (smoothed_rtt == 0):
timeout = 1 second
timeout = 2 * kInitialRtt
return

// Calculate PTO duration
Expand Down