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

[Martin Thomson <[e-mail]>]

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