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

[Mike Bishop <[e-mail]>]

MikeBishop approved this pull request.

Very much nitpicks, and if you merged without them I wouldn't scream.

> -After receiving either a CONNECTION_CLOSE frame or a Public Reset, an
-endpoint MUST NOT send additional packets on that connection. After
-sending either a CONNECTION_CLOSE frame or a Public Reset packet,
-implementations MUST NOT send any non-closing packets on that
-connection. If additional packets are received after this time and
-before idle_timeout seconds has passed, implementations SHOULD respond
-to them by sending a CONNECTION_CLOSE (which MAY just be a duplicate
-of the previous CONNECTION_CLOSE packet) but MAY also send a Public
-Reset packet.  Implementations SHOULD throttle these responses, for
-instance by exponentially backing off the number of packets which are
-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

I think this comment got lost somewhere amongst the commits, so I'll re-add it:  You have "negotiated shutdown" on this line, but "application close" on 1449.  I think consistency would help.

> +from its peer.  These packets might have been sent prior to receiving any close
+signal, or they might be retransmissions of packets for which acknowledgments
+were lost.
+
+The draining period persists for three times the maximum of minimum RTO
+(kMinRTOTimeout) or the round trip time (smoothed_rtt), see {{QUIC-RECOVERY}}
+for descriptions of these values.  During this period, new packets can be
+attributed to the correct connection and acknowledged, but the connection is no
+longer considered active and usable.
+
+Different treatment is given to packets that are received while a connection is
+in the draining period depending on how the connection was closed.  In all
+cases, it is possible to acknowledge packets that are received as normal, but
+other reactions might be preferable depending on how the connection was closed.
+An endpoint that is in a draining period MUST NOT send packets other than ACK,
+PADDING, or CONNECTION_CLOSE.

Nit:  These aren't packets, they're frames.

> +The draining period persists for three times the maximum of minimum RTO
+(kMinRTOTimeout) or the round trip time (smoothed_rtt), see {{QUIC-RECOVERY}}
+for descriptions of these values.  During this period, new packets can be
+attributed to the correct connection and acknowledged, but the connection is no
+longer considered active and usable.
+
+Different treatment is given to packets that are received while a connection is
+in the draining period depending on how the connection was closed.  In all
+cases, it is possible to acknowledge packets that are received as normal, but
+other reactions might be preferable depending on how the connection was closed.
+An endpoint that is in a draining period MUST NOT send packets other than ACK,
+PADDING, or CONNECTION_CLOSE.
+
+Once the draining period has ended, an endpoint SHOULD discard per-connection
+state.  This results in new packets on the connection being discarded.  An
+endpoint MAY use a stateless reset in response to any further incoming packets.

use => send

> +{{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.  A connection enters the draining period when the idle timeout
+expires.  During this time, an endpoint that receives new packets MAY choose to
+restore the connection.  Alternatively, an endpoint that receives packets MAY
+signal the timeout using an immediate close.
+
+
+### Immediate Close
+
+An endpoint sends a CONNECTION_CLOSE frame to terminate the connection
+immediately.  A CONNECTION_CLOSE causes all open streams to immediately become
+closed; open streams can be assumed to be implicitly reset.  After receiving a
+CONNECTION_CLOSE frame, endpoints immediately enter a draining period.

Endpoints presumably enter a draining period after sending a CONNECTION_CLOSE as well, no?

> +expires.  During this time, an endpoint that receives new packets MAY choose to
+restore the connection.  Alternatively, an endpoint that receives packets MAY
+signal the timeout using an immediate close.
+
+
+### Immediate Close
+
+An endpoint sends a CONNECTION_CLOSE frame to terminate the connection
+immediately.  A CONNECTION_CLOSE causes all open streams to immediately become
+closed; open streams can be assumed to be implicitly reset.  After receiving a
+CONNECTION_CLOSE frame, endpoints immediately enter a draining period.
+
+An endpoint that sends a CONNECTION_CLOSE frame SHOULD respond to any packet
+that it receives in the draining period with another packet containing a
+CONNECTION_CLOSE frame.  To reduce the state that an endpoint maintains in this
+case, they MAY send the exact same packet.  However, endpoints SHOULD limit the

they => it, since it's a single endpoint

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