Re: [quicwg/base-drafts] Merge crypto timeout into PTO (#2655)

[MikkelFJ <[e-mail]>]

mikkelfj commented on this pull request.

Overall, it's great to reduce the number of overlapping timers, but see comments.

> +The initial PTO SHOULD be set to twice the initial RTT or 1 second if no
+initial RTT is available as recommended in {{?RFC6298}}.
+
+Until the server has validated the client's address on the path, the amount of
+data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
+If not all unacknowledged CRYPTO data can be sent, then all unacknowledged
+CRYPTO data sent in Initial packets should be retransmitted.  If no data can be
+sent, then no alarm should be armed until data has been received from the
+client.
+
+Because the server could be blocked until more packets are received, the client
+MUST ensure that the crypto retransmission timer is set if there is
+unacknowledged crypto data or if the client does not yet have 1-RTT keys.
+If the crypto retransmission timer expires before the client has 1-RTT keys,
+it is possible that the client may not have any crypto data to retransmit.
+However, the client MUST send a new packet, containing only PING or PADDING

```suggestion
However, the client MUST send a new packet, containing only PADDING
```
PING is not valid nor necessary here, no?

> +the count of bytes in flight.
+
+Endpoints stop sending and receiving Initial packets once they start exchanging
+Handshake packets (see Section 17.2.2.1 of {{QUIC-TRANSPORT}}). 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.  Initial secrets however might be destroyed
+sooner, as soon as handshake keys are available (see Section 4.10 of

Discarding keys based on being declared lost seems odd to me. Either you abandon the handshake, or you discard keys when you are ready to advance to the next PN space, however that is defined. That readiness might involve overlapped PN spaces, waiting for older packets to ACK or to declare lost, but loss alone cannot be the criteria.

> @@ -689,6 +597,69 @@ is received that newly acknowledges packets, loss detection proceeds as
 dictated by packet and time threshold mechanisms, see {{ack-loss-detection}}.
 
 
+## PTO for Crypto Packets
+
+The initial PTO SHOULD be set to twice the initial RTT or 1 second if no
+initial RTT is available as recommended in {{?RFC6298}}.
+
+Until the server has validated the client's address on the path, the amount of
+data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
+If not all unacknowledged CRYPTO data can be sent, then all unacknowledged
+CRYPTO data sent in Initial packets should be retransmitted.  If no data can be
+sent, then no alarm should be armed until data has been received from the
+client.
+

If no alarm is armed, the connection is at the mercy of the client. I supposed connection timeout is not armed yet, and also the wrong metric, but the server needs to be able to time out the connection attempt somehow.

On a related note, text below on Retry/VNEG says they do not ack an Initial, but I suppose they could be used to time out connection state server side?

-- 
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/2655#pullrequestreview-231410100