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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

I like the first paragraph.  I'd lose the second.

> @@ -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.
+
+To speed up handshake completion under these conditions, an endpoint MAY send
+a packet containing unacknowledged CRYPTO data earlier than the PTO expiry,
+subject to address validation limits. (see Section 8.1 of {{QUIC-TRANSPORT}})

```suggestion
subject to address validation limits; see Section 8.1 of {{QUIC-TRANSPORT}}.
```

> +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'm not sure about this paragraph.  It is implying something about packet composition into datagrams that is inconsistent with our general approach.

-- 
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#pullrequestreview-364523510