Re: [quicwg/base-drafts] Retransmit server initial upon second Initial (#3080)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> @@ -508,6 +508,12 @@ until it is certain that the server has finished its address validation
 probe timer if the client has not received an acknowledgement for one of its
 Handshake or 1-RTT packets.
 
+When a server receives duplicate CRYPTO data in an Initial packet after sending
+its Initial flight, it can assume the client did not receive all Initial CRYPTO
+data. To speed handshake completion, it SHOULD retransmit all unacknowledged
+Initial CRYPTO data subject to the path validation limits.  After doing so,
+the PTO is re-armed.
+

There should never be a duplicate packet number unless the network duplicates packets.  That's not a signal of anything on the client.  I think the intent here is to act if the server receives CRYPTO frames that restate one or more already-received bytes.

> @@ -519,6 +519,24 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Up Handshake Completion
+
+When a server receives an Initial packet containing duplicate CRYPTO data,
+it can assume the client did not receive all of the server's CRYPTO data sent
+in Initial packets, or the client's estimated RTT is too small. When a
+client receives Handshake or 1-RTT packets prior to obtaining Handshake keys,
+it may assume some or all of the server's Initial packets were lost.

If you can decrypt them, then clearly the Initial packets you're waiting for weren't lost.

> +Peers can also use coalesced packets to ensure that each datagram elicits at least
+one acknowledgement.  For example, clients can coalesce an Initial packet
+containing PING and PADDING frames with a 0-RTT data packet and a server can
+coalesce an Initial packet containing a PING frame with one or more packets in
+its first flight.

I think what's missing is any description of _why_ an implementation might want to do that except things we don't really want to encourage.  The obvious reading is that clients are tracking whether the datagram was received, inferring that the other packets in that datagram were received but not processed (or processable?), and removing everything in that datagram from bytes-in-flight.  But it doesn't explicitly say that.  I'd either get more explicit, or not make the reference.

-- 
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/3080#discussion_r334609908