Subject: [quicwg/base-drafts] Ignore loss of undecryptable packets (#2028)

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 12:58:09 -0800

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

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

-- Commit Summary --

  * Ignore loss of undecryptable packets

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2028.patch
https://github.com/quicwg/base-drafts/pull/2028.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/2028

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Nov 2018 18:55:00 -0800

martinthomson commented on this pull request.

> @@ -1000,6 +999,17 @@ The recovery period limits congestion window reduction to once per round trip.
 During recovery, the congestion window remains unchanged irrespective of new
 losses or increases in the ECN-CE counter.
 
+## Loss of protected packets during the handshake
+
+0RTT and 1RTT packets sent prior to handshake completion can arrive before

I think that you need to identify this as early RTT packets that are sent by an endpoint with new keys.  Also, expand on that: Handshake and 0-RTT from the client, and 1-RTT from either endpoint.

> @@ -1000,6 +999,17 @@ The recovery period limits congestion window reduction to once per round trip.
 During recovery, the congestion window remains unchanged irrespective of new
 losses or increases in the ECN-CE counter.
 
+## Loss of protected packets during the handshake

Title Case Headings

```suggestion
## Reordering of Packets Sent with New Keys
```

> @@ -1000,6 +999,17 @@ The recovery period limits congestion window reduction to once per round trip.
 During recovery, the congestion window remains unchanged irrespective of new
 losses or increases in the ECN-CE counter.
 
+## Loss of protected packets during the handshake
+
+0RTT and 1RTT packets sent prior to handshake completion can arrive before
+the peer has keys to unprotect them.  In those cases, the peer may decide
+not to buffer the packets.  This will cause the packets to never be

Use paragraphs:

```suggestion
not to buffer the packets.

Discarding packets for which there are no keys will result in the packets never being
```

> @@ -1000,6 +999,17 @@ The recovery period limits congestion window reduction to once per round trip.
 During recovery, the congestion window remains unchanged irrespective of new
 losses or increases in the ECN-CE counter.
 
+## Loss of protected packets during the handshake
+
+0RTT and 1RTT packets sent prior to handshake completion can arrive before
+the peer has keys to unprotect them.  In those cases, the peer may decide
+not to buffer the packets.  This will cause the packets to never be
+acknowledged and eventually declared lost, despite being delivered to
+the peer.  If the server rejects 0RTT, then the congestion controller

Rejecting 0-RTT is a completely different concept that you should separate out.

> @@ -1000,6 +999,17 @@ The recovery period limits congestion window reduction to once per round trip.
 During recovery, the congestion window remains unchanged irrespective of new
 losses or increases in the ECN-CE counter.
 
+## Loss of protected packets during the handshake
+
+0RTT and 1RTT packets sent prior to handshake completion can arrive before
+the peer has keys to unprotect them.  In those cases, the peer may decide
+not to buffer the packets.  This will cause the packets to never be
+acknowledged and eventually declared lost, despite being delivered to
+the peer.  If the server rejects 0RTT, then the congestion controller
+SHOULD ignore the loss of 0RTT packets.  If any 0RTT or 1RTT packets sent
+prior to knowing the peer has keys to unprotect them are lost, the
+sender's congestion control MAY ignore the loss of those packets if it's
+believe they were received by the peer prior to having the correct keys.

```suggestion
believed they were received by the peer prior to having the correct keys.
```

Though I might instead say

>A congestion controller MAY choose to ignore loss signals from packets that might have been discarded due to packet protection keys being unavailable.

That's not complete, or a spec you could implement to, but it is less about belief and more about guesswork, which is what this is.

-- 
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/2028#pullrequestreview-177058417

---

From: Subodh Iyengar <[email-masked]>
Date: Tue, 20 Nov 2018 19:17:12 -0800

siyengar commented on this pull request.

should be consistent about 0-RTT, instead of using "0RTT", "0-RTT" might be better and similar for 1-RTT

this could use some psuedo-code changes as well. Happy to put them up in a separate PR if you want.

-- 
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/2028#pullrequestreview-177062934

---

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Nov 2018 02:34:04 -0800

mikkelfj commented on this pull request.

What if an attacker deliberately sends random packets at high rate? It is not an unlikely attack. Could this shrink the cnwd to the point where valid communication becomes ineffective? If so, it is not a MAY but a MUST.

-- 
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/2028#discussion_r235333193

---

From: Mike Bishop <[email-masked]>
Date: Wed, 21 Nov 2018 09:56:13 -0800

MikeBishop requested changes on this pull request.

Hyphens, wording, etc.  The idea looks fine.

```suggestion
Handshake and 0-RTT packets sent by clients and 1-RTT packets sent by servers
prior to handshake completion can arrive before
```

```suggestion
the peer.  If the server rejects 0-RTT, then the congestion controller
```

```suggestion
SHOULD ignore the loss of 0-RTT packets.  If any 0-RTT or 1-RTT packets sent
```

Traffic injection seems orthogonal to saying that there's a non-congestive form of loss that might get some grace during the handshake.  Injecting enough traffic to overwhelm the link and induce loss can happen at any point in the connection, because it's real loss from real congestion.

-- 
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/2028#pullrequestreview-177364190

---

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Nov 2018 10:14:25 -0800

But the question is if it can be done with far less resources here because it is not only taking bandwidth but also convincing and endpoint to back off. I don't know enough this to really know. It could also be the window is overestimated, which is not such a bad thing in this case.

-- 
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/2028#discussion_r235493381

---

From: janaiyengar <[email-masked]>
Date: Wed, 21 Nov 2018 16:14:58 -0800

I think this could be made a bit more specific:
- loss of Handshake packets and 0-RTT packets SHOULD NOT trigger a CC response.
- loss of 1-RTT packets triggers CC as normal, with one exception. A congestion controller MAY choose to ignore loss signals from packets that might have been discarded due to packet protection keys being unavailable.

-- 
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/2028#issuecomment-440859466

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Nov 2018 16:41:49 -0800

I like that formulation.  It recognizes the problem and recommends a simple solution (ignore for Handshake), but doesn't prohibit implementations from improving on that, or from choosing a simpler implementation that is slightly worse.  It's a corner case that doesn't need tons of spec machinery to support.

-- 
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/2028#issuecomment-440867530

---

From: Rui Paulo <[email-masked]>
Date: Wed, 21 Nov 2018 20:00:26 -0800

I agree with Jana.  Implementations will likely buffer some packets during the handshake so the effect of ignoring cwnd reductions should be negligible.

-- 
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/2028#issuecomment-440906006