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

From: Roni Even <[email-masked]>
Date: Mon, 04 Sep 2017 22:31:46 -0700

section 5.7 "A QUIC endpoint MUST NOT reuse a packet number within the same
   connection (that is, under the same cryptographic keys).  If the
   packet number for sending reaches 2^64 - 1, the sender MUST close the
   connection without sending a CONNECTION_CLOSE frame or any further
   packets;"
 1. I think the first sentence contradicts the Immediate close which allows same packet.
2. Which of the terminating cases  is described in the above text.

-- 
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#issuecomment-327075226

---

From: Roni Even <[email-masked]>
Date: Tue, 05 Sep 2017 06:44:40 -0700

Another question for stateless reset "After the Stateless Reset Token, the endpoint pads the message with an arbitrary number of octets containing random values." is it the endpoint or the server?

-- 
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#issuecomment-327179477

---

From: Patrick McManus <[email-masked]>
Date: Tue, 05 Sep 2017 06:49:06 -0700

the endpoint is the server in this case as only the server generates
stateless reset and could pad it.

On Tue, Sep 5, 2017 at 9:44 AM, Roni Even <[email-masked]> wrote:

> Another question for stateless reset "After the Stateless Reset Token, the
> endpoint pads the message with an arbitrary number of octets containing
> random values." is it the endpoint or the server?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/pull/721#issuecomment-327179477>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAP5s7GJDaYfaMnLNGGdcfk9E4eWmzGGks5sfVBHgaJpZM4O0OWB>
> .
>

-- 
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#issuecomment-327180787

---

From: Roni Even <[email-masked]>
Date: Tue, 05 Sep 2017 14:11:16 +0000 (UTC)

the text should say server since the term endpoint is client or server

-- 
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#issuecomment-327187503

---

From: janaiyengar <[email-masked]>
Date: Wed, 06 Sep 2017 00:19:15 +0000 (UTC)

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Sep 2017 01:27:58 +0000 (UTC)

martinthomson commented on this pull request.

I went with the latter.  I'm trying *really* hard not to say that anything is retransmittable, packets or frames.  I want to keep reinforcing the idea that it's the *contents* of frames (the data or signal) that is retransmitted.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Sep 2017 18:29:11 -0700

@martinthomson pushed 1 commit.

bda9b68  Jana's comments.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/721/files/a215b5312f4a86c45caf13bed624179085196e46..bda9b682c88f2c127e8caf81198ae3d4007f1e3d

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Sep 2017 01:32:53 +0000 (UTC)

Merged #721.

-- 
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#event-1235975151