From 7300b701b53d2f0141b8be76ba636599744efce3 Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 24 Apr 2019 15:31:44 -0400 Subject: [PATCH] Move "Discarding Keys and Packet State" up Move the "Discarding Keys and Packet State" section up a level and out from underneath the Crypto Handshake Timer. This section in no way references the crypto handshake timer, so there's no reason to put it there. It's possible this should be up-leveled out of loss recovery as well? --- draft-ietf-quic-recovery.md | 48 ++++++++++++++++++------------------- 1 file changed, 23 insertions(+), 25 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 2161ab75ea..8c02a9106a 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -570,31 +570,6 @@ packet is received. The client MAY use this value to seed the RTT estimator for a subsequent connection attempt to the server. -### Discarding Keys and Packet State {#discarding-packets} - -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 MUST discard -all recovery state associated with those packets and MUST remove them from -the count of bytes in flight. - -Endpoints stop sending and receiving Initial packets once they start exchanging -Handshake packets (see Section 17.2.2.1 of {{QUIC-TRANSPORT}}). 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. Initial secrets however might be destroyed -sooner, as soon as handshake keys are available (see Section 4.10 of -{{QUIC-TLS}}). - - ## Probe Timeout {#pto} A Probe Timeout (PTO) triggers a probe packet when ack-eliciting data is in @@ -688,6 +663,29 @@ 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}}. +## Discarding Keys and Packet State {#discarding-packets} + +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 MUST discard +all recovery state associated with those packets and MUST remove them from +the count of bytes in flight. + +Endpoints stop sending and receiving Initial packets once they start exchanging +Handshake packets (see Section 17.2.2.1 of {{QUIC-TRANSPORT}}). 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. Initial secrets however might be destroyed +sooner, as soon as handshake keys are available (see Section 4.10 of +{{QUIC-TLS}}). ## Discussion