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

The peer only has 1 key, so PTO both #3597

Merged
merged 2 commits into from Apr 28, 2020
Merged

The peer only has 1 key, so PTO both #3597

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7f887a9
The peer only has 1 key, so send both
ianswett Apr 23, 2020
f440889
Update draft-ietf-quic-recovery.md
ianswett Apr 23, 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
6 changes: 5 additions & 1 deletion draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -597,7 +597,11 @@ All probe packets sent on a PTO MUST be ack-eliciting.

In addition to sending data in the packet number space for which the timer
expired, the sender SHOULD send ack-eliciting packets from other packet
number spaces with in-flight data, coalescing packets if possible.
number spaces with in-flight data, coalescing packets if possible. This is
particularly valuable when the server has both Initial and Handshake data
in-flight or the client has both Handshake and ApplicationData in-flight,
because the peer might only have receive keys for one of the two packet number
spaces.

If the sender wants to elicit a faster acknowledgement on PTO, it can skip a
packet number to eliminate the ack delay.
Expand Down