The only thing I can contribute to this is that we should keep a close
eye on the packet from end0 to end1 to make sure it isn't dropped or
corrupted. In other words, as long as handshaking doesn't fail,
everything is fine.
Kevin
On 3/12/2023 9:01 AM, Kaushal Bhandankar wrote:
As per RFC 9000
1) Every packet SHOULD be acknowledged at least once, and
ack-eliciting packets MUST be acknowledged at least once within the
maximum delay an endpoint communicated using the max_ack_delay
transport parameter
2) An endpoint MUST acknowledge all ack-eliciting Initial and
Handshake packets immediately and all ack-eliciting 0-RTT and 1-RTT
packets within its advertised max_ack_delay
3) A receiver SHOULD send an ACK frame after receiving at least two
ack-eliciting packets.
When the SERVER sends a CRYPTO frame containing SERVER HELLO, it can
continue sending HANDSHAKE packets.
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.
What should be the correct behaviour ?
1. If Client does not ACK the SERVER HELLO, should the packet be
retransmitted even after HANDSHAKE is completed ?
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.
Regards,
Kaushal
Regards,
Kaushal
