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

[Mike Bishop <[e-mail]>]

MikeBishop requested changes on this pull request.

Hyphens, wording, etc.  The idea looks fine.

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

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

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

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

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

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

> @@ -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.

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