Parsing Ack Delay without ack_delay_exponent #1007
Labels
-transport
design
An issue that affects the design of the protocol; resolution requires consensus.
has-consensus
An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Unfortunately Handshake (and Retry) packets can contain ACK frames and be delivered before the transport parameters are provided to QUIC. The ack delay field of the ACK frame cannot be interpreted without the ack_delay_exponent from the transport parameters. This brings back memories of flow control and stream 0.
There are several ways to resolve this, but I'll suggest that non protected packets that contain ACK frames are always encoded with the default ack_delay_exponent.
The text was updated successfully, but these errors were encountered: