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

[janaiyengar <[e-mail]>]

janaiyengar approved this pull request.

A few nits, mostly editorial. LGTM'ing -- please feel free to merge once you've addressed these.

> +
+* application close ({{application-close}})
+* idle timeout ({{idle-timeout}})
+* immediate close ({{immediate-close}})
+* stateless reset ({{stateless-reset}})
+
+
+### Draining Period {#draining}
+
+After a connection is closed for any reason, an endpoint might receive packets
+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}}

I'm sorry if I mis-spoke, I would simply say "three times the RTO, see {{QUIC-RECOVERY}}." The RTO value is basically a max(minRTO, f(smoothed_rtt, rtt_variance)), and 3 times the RTO value allows for two consecutive timeout periods.

> +* idle timeout ({{idle-timeout}})
+* immediate close ({{immediate-close}})
+* stateless reset ({{stateless-reset}})
+
+
+### Draining Period {#draining}
+
+After a connection is closed for any reason, an endpoint might receive packets
+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

nit: remove phrase "attributed to the correct connection and". Seems unnecessary.

> +* immediate close ({{immediate-close}})
+* stateless reset ({{stateless-reset}})
+
+
+### Draining Period {#draining}
+
+After a connection is closed for any reason, an endpoint might receive packets
+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.

nit: instead of "the connection is no longer considered active and usable", how about "no new data or retransmittable packets may be sent on the connection"? The allowable frames are elucidated below, so I'd be happy with just "no new data may be sent on the connection."

> +immediately.  A CONNECTION_CLOSE causes all open streams to immediately become
+closed; open streams can be assumed to be implicitly reset.  After sending or
+receiving a CONNECTION_CLOSE frame, endpoints immediately enter a draining
+period.
+
+During the draining period, an endpoint that sends a CONNECTION_CLOSE frame
+SHOULD respond to any subsequent packet that it receives with another packet
+containing a CONNECTION_CLOSE frame.  To reduce the state that an endpoint
+maintains in this case, it MAY send the exact same packet.  However, endpoints
+SHOULD limit the number of CONNECTION_CLOSE messages they generate.  For
+instance, an endpoint could progressively increase the number of packets that it
+receives before sending additional CONNECTION_CLOSE frames.
+
+Note:
+
+: Allowing retransmision of a packet contradicts other advice in this document

typo: retransmision --> retransmission

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