Re: [quicwg/base-drafts] Don't arm the handshake timer if there's no data (#2590)

[Marten Seemann <[e-mail]>]

marten-seemann commented on this pull request.



> @@ -458,17 +462,16 @@ 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 start the crypto retransmission timer even if there is no unacknowledged
-CRYPTO data.  If the timer expires and the client has no CRYPTO data to
-retransmit and does not have Handshake keys, it SHOULD send an Initial packet in
-a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it
-SHOULD send a Handshake packet.
-
-On each consecutive expiration of the crypto timer without receiving an
-acknowledgement for a new packet, the sender SHOULD double the crypto
-retransmission timeout and set a timer for this period.
+MUST ensure the crypto retransmission timer is set if there is unacknowledged
+crypto data and MUST ensure the timer is set until it has 1-RTT keys.
+If the timer expires and the client has no CRYPTO data to retransmit and does
+not have Handshake keys, it MUST send an Initial packet in a UDP datagram of
+at least 1200 bytes.  If the client has Handshake keys, it MUST send a

Why would the client send a Handshake packet if there’s no CRYPTO data to retransmit? If there’s no Handshake CRYPTO data to retransmit, this means that the server already received the client‘s TLS messages sent with Handshake keys, and won’t be blocked by the 3x Limit any more, doesn’t it?

-- 
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/2590#pullrequestreview-223632964