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

Move a PTO section up #3654

Merged
merged 2 commits into from May 14, 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
19 changes: 7 additions & 12 deletions draft-ietf-quic-recovery.md
Expand Up @@ -475,8 +475,13 @@ and larger thresholds increase loss detection delay.

A Probe Timeout (PTO) triggers sending one or two probe datagrams when
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 acknowledgements.
time or the server may not have validated the client's address. A PTO enables
a connection to recover from loss of tail packets or acknowledgements.

A PTO timer expiration event does not indicate packet loss and MUST NOT cause
prior unacknowledged packets to be marked as lost. When an acknowledgement
is received that newly acknowledges packets, loss detection proceeds as
dictated by packet and time threshold mechanisms; see {{ack-loss-detection}}.

As with loss detection, the probe timeout is per packet number space.
The PTO algorithm used in QUIC implements the reliability functions of
Expand Down Expand Up @@ -658,16 +663,6 @@ and ensures the highest priority frames arrive first. Sending different
payloads each time reduces the chances of spurious retransmission.


### Loss Detection {#pto-loss}

Delivery or loss of packets in flight is established when an ACK frame is
received that newly acknowledges one or more packets.

A PTO timer expiration event does not indicate packet loss and MUST NOT cause
prior unacknowledged packets to be marked as lost. When an acknowledgement
is received that newly acknowledges packets, loss detection proceeds as
dictated by packet and time threshold mechanisms; see {{ack-loss-detection}}.

## Handling Retry Packets

A Retry packet causes a client to send another Initial packet, effectively
Expand Down