Subject: [quicwg/base-drafts] Discard 0-RTT packet state when rejected (#2300)

From: ianswett <[email-masked]>
Date: Sun, 06 Jan 2019 13:30:32 -0800

Replaces part of #2028

Fixes part of #1967
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2300

-- Commit Summary --

  * Discard 0-RTT packet state when rejected

-- File Changes --

    M draft-ietf-quic-recovery.md (21)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2300.patch
https://github.com/quicwg/base-drafts/pull/2300.diff

-- 
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/2300

---

From: Martin Thomson <[email-masked]>
Date: Sun, 06 Jan 2019 16:11:14 -0800

martinthomson commented on this pull request.

Good changes, some editorial feedback though.

> @@ -1001,12 +1001,21 @@ after idle periods, such as those proposed for TCP in {{?RFC7661}}.
 
 ## Discarding Packet Number Space State
 
-When keys for an packet number space are discarded, any packets sent with those
-keys are removed from the count of bytes in flight.  No loss events will occur
-any in-flight packets from that space, as a result of discarding loss recovery
-state (see {{discard-initial}}).  Note that it is expected that keys are
-discarded after those packets would be declared lost, but Initial secrets are
-destroyed earlier.
+When keys for an packet number space are discarded, any in-flight packets
+sent with those keys are removed from the count of bytes in flight.  Loss
+recovery state is also discarded, so no loss events will occur for any
+in-flight packets from that space(see {{discard-initial}}).  Note that it is
+expected that keys are discarded after those packets would be declared lost,
+but Initial secrets are destroyed earlier.
+
+## Discarding 0-RTT packet state

I wouldn't bother with the section heading here.

> @@ -1001,12 +1001,21 @@ after idle periods, such as those proposed for TCP in {{?RFC7661}}.
 
 ## Discarding Packet Number Space State
 
-When keys for an packet number space are discarded, any packets sent with those
-keys are removed from the count of bytes in flight.  No loss events will occur
-any in-flight packets from that space, as a result of discarding loss recovery
-state (see {{discard-initial}}).  Note that it is expected that keys are
-discarded after those packets would be declared lost, but Initial secrets are
-destroyed earlier.
+When keys for an packet number space are discarded, any in-flight packets
+sent with those keys are removed from the count of bytes in flight.  Loss
+recovery state is also discarded, so no loss events will occur for any
+in-flight packets from that space(see {{discard-initial}}).  Note that it is

```suggestion
in-flight packets from that space (see {{discard-initial}}).  Note that it is
```

(Oh good, GitHub fixed the leading space problem.)

> -When keys for an packet number space are discarded, any packets sent with those
-keys are removed from the count of bytes in flight.  No loss events will occur
-any in-flight packets from that space, as a result of discarding loss recovery
-state (see {{discard-initial}}).  Note that it is expected that keys are
-discarded after those packets would be declared lost, but Initial secrets are
-destroyed earlier.
+When keys for an packet number space are discarded, any in-flight packets
+sent with those keys are removed from the count of bytes in flight.  Loss
+recovery state is also discarded, so no loss events will occur for any
+in-flight packets from that space(see {{discard-initial}}).  Note that it is
+expected that keys are discarded after those packets would be declared lost,
+but Initial secrets are destroyed earlier.
+
+## Discarding 0-RTT packet state
+
+When 0-RTT is rejected, all in-flight 0-RTT packets still are removed from

```suggestion
When 0-RTT is rejected, all in-flight 0-RTT packets are removed from
```

> -any in-flight packets from that space, as a result of discarding loss recovery
-state (see {{discard-initial}}).  Note that it is expected that keys are
-discarded after those packets would be declared lost, but Initial secrets are
-destroyed earlier.
+When keys for an packet number space are discarded, any in-flight packets
+sent with those keys are removed from the count of bytes in flight.  Loss
+recovery state is also discarded, so no loss events will occur for any
+in-flight packets from that space(see {{discard-initial}}).  Note that it is
+expected that keys are discarded after those packets would be declared lost,
+but Initial secrets are destroyed earlier.
+
+## Discarding 0-RTT packet state
+
+When 0-RTT is rejected, all in-flight 0-RTT packets still are removed from
+the count of bytes in flight.  Loss recovery state is also discarded, so no
+loss events will occur for any in-flight 0-RTT packets.  If a server does not

The sentence starting "Loss recovery state" is duplicative of the previous section/paragraph, so can go.

> -destroyed earlier.
+When keys for an packet number space are discarded, any in-flight packets
+sent with those keys are removed from the count of bytes in flight.  Loss
+recovery state is also discarded, so no loss events will occur for any
+in-flight packets from that space(see {{discard-initial}}).  Note that it is
+expected that keys are discarded after those packets would be declared lost,
+but Initial secrets are destroyed earlier.
+
+## Discarding 0-RTT packet state
+
+When 0-RTT is rejected, all in-flight 0-RTT packets still are removed from
+the count of bytes in flight.  Loss recovery state is also discarded, so no
+loss events will occur for any in-flight 0-RTT packets.  If a server does not
+buffer out-of-order packets and accepts 0-RTT, there is a chance of declaring
+0-RTT packets lost that were actually discarded by the server, but this is
+expected to be infrequent.

The out-of-order sentence probably needs to be its own paragraph - because it's talking about accepting 0-RTT (as opposed to rejecting it).  Not sure how that affects the flow of the section though.

-- 
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/2300#pullrequestreview-189651688

---

From: ianswett <[email-masked]>
Date: Mon, 07 Jan 2019 20:01:01 -0800

@ianswett pushed 1 commit.

961110bc17cd820a3e60c5fb5f6ae5ec40ce448b  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2300/files/d47696a10bc38230a21761d4da3bcc24d7adc38b..961110bc17cd820a3e60c5fb5f6ae5ec40ce448b

---

From: ianswett <[email-masked]>
Date: Mon, 07 Jan 2019 20:01:33 -0800

88d179276d315688ef626d809cb2d255d5c96cf9  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2300/files/961110bc17cd820a3e60c5fb5f6ae5ec40ce448b..88d179276d315688ef626d809cb2d255d5c96cf9

---

From: ianswett <[email-masked]>
Date: Mon, 07 Jan 2019 20:02:37 -0800

85ed4cc9a7be717b2c3ba0f2f92656331f1909a9  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2300/files/88d179276d315688ef626d809cb2d255d5c96cf9..85ed4cc9a7be717b2c3ba0f2f92656331f1909a9

---

From: ianswett <[email-masked]>
Date: Mon, 07 Jan 2019 20:08:08 -0800

b37a2788422656407f49a7d5c788b212580d6078  Martin's suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2300/files/85ed4cc9a7be717b2c3ba0f2f92656331f1909a9..b37a2788422656407f49a7d5c788b212580d6078

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Jan 2019 21:22:36 -0800

martinthomson approved this pull request.

I assume that the "fixes part of" will be addressed separately.

-- 
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/2300#pullrequestreview-190095947

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 07 Jan 2019 21:35:20 -0800

kazuho commented on this pull request.

Do we need to care about loss?

I ask this based on the assumption that a server will retain the 0-RTT read key for 3 PTO after obtaining 1-RTT read key.

-- 
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/2300#discussion_r245881971

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Jan 2019 21:38:15 -0800

The problem here is that reordering will manifest as loss, that's all.  As the text says, that's rare, and the effect is limited to having to send the data again and maybe having congestion windows docked.

-- 
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/2300#discussion_r245882263

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 07 Jan 2019 21:47:00 -0800

My bad. I incorrectly assumed that the text is talking about 0-RTT packets arriving late. Actually, it is talking about 0-RTT packets arriving before Initial.

I am not sure if others would have the same confusion as I had, but changing "but does not buffer out of order packets and there is reordering" to "but does not buffer 0-RTT packets arriving before Initial packets" might better clarify what is being discussed here.

-- 
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/2300#discussion_r245883363

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Jan 2019 21:48:10 -0800

That would be an improvement, I agree.

-- 
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/2300#discussion_r245883497

---

From: ianswett <[email-masked]>
Date: Tue, 08 Jan 2019 07:45:22 -0800

6f41eb37aea26827e1ea170d39846baf5d288cdd  Kazuho's suggestion

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2300/files/b37a2788422656407f49a7d5c788b212580d6078..6f41eb37aea26827e1ea170d39846baf5d288cdd

---

From: MikkelFJ <[email-masked]>
Date: Tue, 08 Jan 2019 16:02:42 +0000 (UTC)

mikkelfj commented on this pull request.

> @@ -1001,12 +1001,20 @@ after idle periods, such as those proposed for TCP in {{?RFC7661}}.

```suggestion
When keys for a packet number space are discarded, any in-flight packets
```

-- 
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/2300#pullrequestreview-190314666

---

From: ianswett <[email-masked]>
Date: Tue, 08 Jan 2019 08:10:58 -0800

06a2730bf9365697de226cb337899329230952ff  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2300/files/6f41eb37aea26827e1ea170d39846baf5d288cdd..06a2730bf9365697de226cb337899329230952ff

---

From: ianswett <[email-masked]>
Date: Tue, 08 Jan 2019 23:46:39 +0000 (UTC)

Merged #2300 into master.

-- 
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/2300#event-2061621104