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

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.

Thanks, Martin. A few comments, inline.

> -received before sending a response.  After this time, implementations
-SHOULD respond to unexpected packets with a Public Reset packet.
-
-
-## Stateless Reset {#stateless-reset}
+of four ways: negotiated shutdown, idle timeout, immediate close, and a
+connection reset.
+
+
+### Negotiated Shutdown
+
+An application protocol might arrange to abandon a connection after negotiating
+a graceful shutdown.  The application protocol exchanges whatever messages that
+are needed to cause both endpoints to agree to close the connection, after which
+the connection is closed.  A negotiated shutdown might not result in exchanging
+messages that are visible to the transport.

I don't understand what QUIC mechanism this is discussing -- specifically, why is this a QUIC connection termination mechanism? It seems to suggest that the app can use its own signaling to determine when to shutdown, but what QUIC mechanism is used for shutdown?

> +the connection is closed.  A negotiated shutdown might not result in exchanging
+messages that are visible to the transport.
+
+
+### Idle Timeout
+
+A connection that remains idle for longer than the idle timeout (see
+{{transport-parameter-definitions}} becomes closed.  Either peer removes
+connection state if they have neither sent nor received a packet for this time.
+
+The time at which an idle timeout takes effect won't be perfectly synchronized
+on peers.  Endpoints might allow for the possibility that the remote side might
+attempt to send packets before the timeout.  In this case, an endpoint might
+choose to retain enough information to generate a CONNECTION_CLOSE.  Endpoints
+MAY instead rely on sending Public Reset in response to packets that arrive
+after an idle timeout.

I don't think this advice is correct or adequate -- the time can be synchronized reasonably well. I would leave this subsection as is, if it needs to change in the future anyways.

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

The current text says idle_timeout period of time, since that's the amount of time after which we expect the peer to drop state anyways. Is there a reason to change that?

SImilarly, the current text recommends throttling responses, which is really important. I would argue for retaining that.

-- 
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#pullrequestreview-56223350