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

Clarify when the PTO may need to be recomputed and reset #3665

Merged
merged 8 commits into from May 19, 2020
Merged

Clarify when the PTO may need to be recomputed and reset #3665

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
32ee545
Clarify when the PTO may need to be recomputed and reset
ianswett May 18, 2020
40e8c84
Update draft-ietf-quic-recovery.md
ianswett May 18, 2020
f9bde12
Apply suggestions from code review
ianswett May 19, 2020
54659b1
Update draft-ietf-quic-recovery.md
ianswett May 19, 2020
03d2902
Martin's suggested reworked
ianswett May 19, 2020
a1618e8
Update draft-ietf-quic-recovery.md
ianswett May 19, 2020
e4919c2
Update draft-ietf-quic-recovery.md
janaiyengar May 19, 2020
21607ae
reflow
martinthomson May 19, 2020
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
12 changes: 6 additions & 6 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -530,12 +530,12 @@ a PTO expiration before it has the keys to process an acknowledgement.
When a PTO timer expires, the PTO backoff MUST be increased, resulting in the
PTO period being set to twice its current value. The PTO backoff factor is reset
when an acknowledgement is received, except in the following case. A server
might take longer to respond to packets during the handshake than otherwise.
To protect such a server from repeated client probes, the PTO backoff is not
reset at a client that is not yet certain that the server has finished validating
the client's address. That is, a client does not reset the PTO backoff factor on
receiving acknowledgements until it receives a HANDSHAKE_DONE frame or
an acknowledgement for one of its Handshake or 1-RTT packets.
might take longer to respond to packets during the handshake than otherwise. To
protect such a server from repeated client probes, the PTO backoff is not reset
at a client that is not yet certain that the server has finished validating the
client's address. That is, a client does not reset the PTO backoff factor on
receiving acknowledgements until it receives a HANDSHAKE_DONE frame or an
acknowledgement for one of its Handshake or 1-RTT packets.

This exponential reduction in the sender's rate is important because
consecutive PTOs might be caused by loss of packets or acknowledgements due to
Expand Down