Re: [quicwg/base-drafts] Backoff on CONNECTION_CLOSE (#3157)

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



> -containing a CONNECTION_CLOSE frame.  To minimize the state that an endpoint
-maintains for a closing connection, endpoints MAY send the exact same packet.
-However, endpoints SHOULD limit the number of packets they generate containing a
-CONNECTION_CLOSE frame.  For instance, an endpoint could progressively increase
-the number of packets that it receives before sending additional packets or
-increase the time between packets.
+After sending a CONNECTION_CLOSE frame, an endpoint immediately enters the
+closing state.  During the closing period, an endpoint that sends a
+CONNECTION_CLOSE frame SHOULD respond to any packet that it receives with
+another packet containing a CONNECTION_CLOSE frame, until it receives a packet
+that contains a CONNECTION_CLOSE frame.  However, such an endpoint SHOULD limit
+the number of packets it generates containing a CONNECTION_CLOSE frame.  For
+instance, an endpoint could progressively increase the number of packets that it
+receives before sending additional packets or increase the time between packets.
+An endpoint that drops the packet protection keys when entering the closing
+period and therefore being unable to decrypt the incoming packets MUST

Thank you.

Applied @martinthomson's suggestion in a45ded2. I do not think "exponentially" is required here, there could be other approaches, such as limiting the emission of CONNECTION_CLOSE to once every PTO.

-- 
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/3157#discussion_r339847895