On Mon, Mar 13, 2023, at 03:01, Kaushal Bhandankar wrote: > There are some client implementations which do not send ACK in INITIAL > packet space for SERVER HELLO crypto frame. I have seen it in Firefox, > picoquic, msquic. The Handshake is still successful and 1RTT packets > can be seen in the packet capture.
Yes, there are some clients that follow the requirement to drop the keys for the Initial packet number space before generating an acknowledgment. This means that a server Initial won't be acknowledged directly. The use of Handshake packets implicitly acknowledges the ServerHello, but the server can only infer that. (Making that inference can improve congestion control performance as marking the packet as received can contribute to congestion window expansion, whereas dropping the number space means that the opportunity is lost; either of those options is better than inferring a loss.) Some background: Firefox used to send a single Initial packet with an acknowledgment, but we had to remove that capability as some server implementations used the fact that the datagram was small as a reason to drop the subsequent Handshake packet, which badly affected performance. > 1. If Client does not ACK the SERVER HELLO, should the packet be > retransmitted even after HANDSHAKE is completed ? A strict following of the retransmissions rules would result in the data being retransmitted, however, the server is also required to drop the Initial packet number space once it receives a Handshake packet. So it would not be able to retransmit after that point. > 2. Should the client immediately ACK the SERVER HELLO, since no more > packets may be exchanged in INITIAL packet space. This will be > contradicting the point 3 above from RFC. This rule applies to Initial and Handshake packets: > An endpoint MUST acknowledge all ack-eliciting Initial and Handshake packets > immediately [...] -- https://quicwg.org/base-drafts/rfc9000.html#section-13.2.1-2
