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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -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
+first Handshake packet.  A server stops sending and accepting Initial packets
+when it receives its first Handshake packet.  Though packets might still be in
+flight or awaiting acknowledgment, no further Initial packets need to be
+exchanged beyond this point.  Initial packet protection keys are discarded (see
+Section 4.10 of {{QUIC-TLS}}) along with any loss recovery and congestion
+control state (see Sections 5.3.1.2 and 6.9 of {{QUIC-RECOVERY}}).

I don't think that it is the case.  We don't really say anything from a loss recovery perspective - the packets are not declared lost.  The congestion controller is just told to remove the bytes from in flight - they don't cause the CWND to increase.  So it's not really acknowledgment.

As the changes to the recovery draft state: loss recovery state is just thrown out: you won't be retransmitting anything at the encryption level.  So saying anything more isn't really helpful there.  The effect on the congestion controller is intentionally neutral: don't increase CWND as though the packets got through, but don't keep the bytes on the books as though the packets were lost.

Or have I screwed this up?

-- 
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#discussion_r237332488