Re: [quicwg/base-drafts] Refactor the section on connection termination (#721)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> +an endpoint maintains in this case, they MAY send the exact same
+CONNECTION_CLOSE packet.
+
+Note:
+
+: This intentionally contradicts other advice in this document that recommends
+  the creation of new packet numbers for every packet.  Sending new packet
+  numbers is primarily of advantage to loss recovery and congestion control,
+  which are not expected to be relevant for a closed connection.  Retransmitting
+  the final packet requires less state at the server.
+
+Implementations SHOULD limit the number of CONNECTION_CLOSE messages they
+generate.  For instance, an implementation could exponentially increase the
+number of packets that it receives before sending the packet containing
+CONNECTION_CLOSE.  Once enough time has passed to allow a peer to receive the
+CONNECTION_CLOSE, an endpoint SHOULD discard per-connection state and MAY

If the idle timeout is 2 minutes, then that is far larger than the time you might wait to have the other side receive the close.  Unreasonably so in my view.  2xRTT is probably adequate.

As for retaining text on throttling, that's right at the start of this paragraph: 

> Implementations SHOULD limit the number of CONNECTION_CLOSE messages they generate. 

-- 
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/721#discussion_r133101553