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

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



> @@ -2379,15 +2379,23 @@ terminate the connection immediately.  A CONNECTION_CLOSE frame causes all
 streams to immediately become closed; open streams can be assumed to be
 implicitly reset.
 
-After sending a CONNECTION_CLOSE frame, endpoints immediately enter 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.  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 incoming packet that can be decrypted with another packet

Could you please elaborate a bit more?

My understanding is that we need "that can be decrypted." The reason we are adding MUST for endpoints that drop the keys when entering the closing state is because they cannot validate the packet using the keys. In this paragraph, we are talking about the flip side. That means that the endpoints MUST validate the incoming packets by unprotecting them.

Or are you specifically suggesting that we need to talk about how duplicates are to be handled?

-- 
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_r339889443