Re: [quicwg/base-drafts] Ignore packet loss when the keys are not available (#2327)

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.

A few comments, editorial.

>  
+When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is
+discarded.
+
+If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive
+before Initial packets, early 0-RTT packets will be declared lost, but that
+is expected to be infrequent.
+
+#### Ignoring Loss of Undecryptable Packets

This doesn't belong here. You want this in the CC section.

> @@ -427,15 +445,34 @@ packet is received.  The client MAY use this value to seed the RTT estimator for
 a subsequent connection attempt to the server.
 
 
-#### Discarding Initial State {#discard-initial}
+#### Discarding Keys and Packet State {#discarding-packets}
+
+When packet protection keys are discarded (see Section 4.9 of {{QUIC-TLS}}),
+recovery state for all in-flight packets sent with those keys is discarded.

I think a slight restructure might help make this text clearer. I've also rephrased some.

"When packet protection keys are discarded (see Section 4.9 of {{QUIC-TLS}}),
all packets that were sent with those keys can no longer be acknowledged because
their acknowledgements cannot be processed anymore. The sender considers them
no longer in flight.  That is, the sender SHOULD discard all recovery state associated
with those packets and MUST remove them from the count of bytes in flight.

As described in Section 17.5.1 of {{QUIC-TRANSPORT}}, endpoints stop sending and
receiving Initial packets once they start exchanging Handshake packets.  At this
point, recovery state for all in-flight Initial packets is discarded.

When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is
discarded.

If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive
before Initial packets, early 0-RTT packets will be declared lost, but that
is expected to be infrequent.

It is expected that keys are discarded after packets encrypted with them would be
acknowledged or declared lost, with the exception of Initial secrets, which might
destroyed earlier."


> @@ -427,15 +445,34 @@ packet is received.  The client MAY use this value to seed the RTT estimator for
 a subsequent connection attempt to the server.
 
 
-#### Discarding Initial State {#discard-initial}
+#### Discarding Keys and Packet State {#discarding-packets}
+
+When packet protection keys are discarded (see Section 4.9 of {{QUIC-TLS}}),
+recovery state for all in-flight packets sent with those keys is discarded.
+The packets are removed from the count of bytes in flight and no
+acknowledgements or loss events will occur for those packets.  Note that it
+is expected that keys are discarded after those packets would be declared lost,
+but Initial secrets are destroyed earlier.

I don't understand this last sentence. Can you rephrase?

>  
+When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is
+discarded.
+
+If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive
+before Initial packets, early 0-RTT packets will be declared lost, but that
+is expected to be infrequent.
+
+#### Ignoring Loss of Undecryptable Packets
+
+During the handshake, some packet protection keys might not be
+available when a packet arrives. In particular, Handshake and 0-RTT packets
+can't be processed until the Initial flight arrives and 1-RTT packets

```suggestion
cannot be processed until the Initial packets arrive, and 1-RTT packets
```

>  
+When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is
+discarded.
+
+If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive
+before Initial packets, early 0-RTT packets will be declared lost, but that
+is expected to be infrequent.
+
+#### Ignoring Loss of Undecryptable Packets
+
+During the handshake, some packet protection keys might not be
+available when a packet arrives. In particular, Handshake and 0-RTT packets
+can't be processed until the Initial flight arrives and 1-RTT packets
+can't be processed until the handshake completes.  Endpoints MAY

```suggestion
cannot be processed until the handshake completes.  Endpoints MAY
```

>  
+When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is
+discarded.
+
+If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive
+before Initial packets, early 0-RTT packets will be declared lost, but that
+is expected to be infrequent.
+
+#### Ignoring Loss of Undecryptable Packets
+
+During the handshake, some packet protection keys might not be
+available when a packet arrives. In particular, Handshake and 0-RTT packets
+can't be processed until the Initial flight arrives and 1-RTT packets
+can't be processed until the handshake completes.  Endpoints MAY
+ignore the loss of Handshake, 0-RTT, and 1-RTT packets that arrive before the

```suggestion
ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might arrive before the
```

-- 
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/2327#pullrequestreview-192936478