Ignore packet loss when the keys are not available #2327
Conversation
ianswett
changed the title
ianswett
changed the title
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
martinthomson
added
editorial
draft-ietf-quic-recovery.md
Outdated
| #### Discarding Keys and Packet State {#discarding-packets} | ||
|
|
||
| When packet protection keys are discarded (see Section 4.9 of {{QUIC-TLS}}), | ||
| recovery state for all in-flight packets sent with those keys is discarded. |
There was a problem hiding this comment.
I think a slight restructure might help make this text clearer. I've also rephrased some.
"When packet protection keys are discarded (see Section 4.9 of {{QUIC-TLS}}),
all packets that were sent with those keys can no longer be acknowledged because
their acknowledgements cannot be processed anymore. The sender considers them
no longer in flight. That is, the sender SHOULD discard all recovery state associated
with those packets and MUST remove them from the count of bytes in flight.
As described in Section 17.5.1 of {{QUIC-TRANSPORT}}, endpoints stop sending and
receiving Initial packets once they start exchanging Handshake packets. At this
point, recovery state for all in-flight Initial packets is discarded.
When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is
discarded.
If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive
before Initial packets, early 0-RTT packets will be declared lost, but that
is expected to be infrequent.
It is expected that keys are discarded after packets encrypted with them would be
acknowledged or declared lost, with the exception of Initial secrets, which might be
destroyed earlier."
draft-ietf-quic-recovery.md
Outdated
| The packets are removed from the count of bytes in flight and no | ||
| acknowledgements or loss events will occur for those packets. Note that it | ||
| is expected that keys are discarded after those packets would be declared lost, | ||
| but Initial secrets are destroyed earlier. |
There was a problem hiding this comment.
I don't understand this last sentence. Can you rephrase? Specifically, the Initial secrets are destroyed earlier than what event?
There was a problem hiding this comment.
IIUC this refers to the provision in https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.4.10. Maybe it's worth adding a reference.
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
draft-ietf-quic-recovery.md
Outdated
| ins: S. Turner | ||
| name: Sean Turner | ||
| org: sn3rd | ||
| email: sean@sn3rd.com |
There was a problem hiding this comment.
| email: sean@sn3rd.com |
|
merging this one as well to get this in -18. |
Ignore the loss of Handshake, 0-RTT, and 1-RTT packets if the peer doesn't have the keys to process them.
Also unifies the text on discarding keys and no longer implies that 0-RTT has it's own packet number space.
Fixes #1967 Replaces #2028