Re: [quicwg/base-drafts] Discard Initial keys as soon as possible (#2045)

[ianswett <[e-mail]>]

ianswett commented on this pull request.

Thanks Martin, I think this is now fairly close.

> @@ -3592,6 +3594,21 @@ and will contain a CRYPTO frame with an offset matching the size of the CRYPTO
 frame sent in the first Initial packet.  Cryptographic handshake messages
 subsequent to the first do not need to fit within a single UDP datagram.
 
+
+### Abandoning Initial Packets {#discard-initial}
+
+A client stops both sending and accepting Initial packets when it sends its

This draft uses packet processing, and accepting for things like "accepting" new connections, so I think processing is better here and on 3601

> @@ -1059,6 +1084,15 @@ A sender that does not use pacing SHOULD reset its congestion window to the
 minimum of the current congestion window and the initial congestion window.
 This recommendation is based on Section 4.1 of {{?RFC5681}}.
 
+## In-Flight Packet Accounting
+
+When keys for an packet number space are discarded (see {{QUIC-TLS}}), any
+packets sent with those keys are removed from the count of bytes in flight.  No

clarification: any in-flight packets sent with those keys

> @@ -439,6 +456,14 @@ Either packet indicates that the Initial was received but not processed.
 Neither packet can be treated as an acknowledgment for the Initial, but they MAY
 be used to improve the RTT estimate.
 
+#### Discarding Initial State {#discard-initial}
+
+As described in Section 4.10 of {{QUIC-TLS}}, endpoints stop sending and

I think it makes more sense to reference the transport draft, now that it has the required text.  Also, it's a bit odd to have the recovery draft have a direct dependency on TLS.

Most of this paragraph seems to apply to the Handshake encryption level as well, correct?  

> @@ -1059,6 +1084,15 @@ A sender that does not use pacing SHOULD reset its congestion window to the
 minimum of the current congestion window and the initial congestion window.
 This recommendation is based on Section 4.1 of {{?RFC5681}}.
 
+## In-Flight Packet Accounting

I would call this section something else like "Discarding Keys" or "Abandoning Encryption Levels"

> @@ -439,6 +456,14 @@ Either packet indicates that the Initial was received but not processed.
 Neither packet can be treated as an acknowledgment for the Initial, but they MAY
 be used to improve the RTT estimate.
 
+#### Discarding Initial State {#discard-initial}
+
+As described in Section 4.10 of {{QUIC-TLS}}, endpoints stop sending and
+receiving Initial packets once they start exchanging Handshake packets.  At this
+point, all loss recovery state for the Initial packet number space is also
+discarded.  After discarding state, new Initial packets will not be sent and no

```suggestion
discarded without declaring them acknowledged or lost.  After discarding state, new Initial packets will not be sent.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2045#pullrequestreview-183998679