Draft: draft-ietf-quic-ack-frequency

Commentary: I found an interesting regression when implementing the delayed ack extension . The extension allows the sender of the data to control the  ack delay and the ack gap . In general that 's a good idea , but not for the 2 RTT of the connection . Once the client obtains the 1RTT key , it will start receiving data sent by the server in " false start " . At that point the client has assessed the RTT of the connection , but the server has not . The "  ack delay " sent by the server is a guess based on statistics . It will typically be longer than recommended values like RTT/4 . The effect is that the first ACKs are sent too late , which has a cascading effect with some congestion control algorithms . My fix was to use the values locally computed by the client until the session is confirmed and the server can send accurate " ack frequency " frames . Not sure whether we should have text about that in the draft . 
 I 'm not completely clear on the details here , so hopefully you can clarify . Is the server sending an ACK_FREQUENCY frame in 0.5RTT before it has any RTT samples ? If so , yes I would say that 's a bad idea and we should add a SHOULD NOT to advise against that . And the regression is that slow start is slowed down substantially vs the default behavior of sending an ACK every 2 packets ? Or is there another regression ? Possibly this issue is a variation on about recommendations and potential pitfalls of this extension frame ? 
 At 0.5 RTT , the server will start sending data frames : HTTP settings for example , or maybe responses to client requests in 0 - RTT packets . As you say , the server should not send an ACK FREQUENCY frame in 0.5RTT before it has any RTT samples . Let 's assume it does n't . The client knows that    has been negotiated . In that case , my first implementation of the extension was completely deferring to the server , and just setting    to the parameter advertised by the server . After all , the draft does says that the ACK FREQUENCY frame carries an update to the peer 's " maxackdelay " transport parameter . That was be by the book . But it was also causing regressions in a number of performance tests , because the value in the TP is typically an upper bound . The acks were sent too late , the connection was ramping up too slowly . 
 Thanks , presumably the client is setting " Packet Tolerance " to a value larger than 2 in its ACK_FREQUENCY frame ? If so , that makes sense . In the " Motivations " section , the existing draft says : " Starting a connection up quickly without inducing excess queue is important for latency reduction , for both short and long flows . The sender often needs more frequent acknowledgments during this phase . " But maybe there needs to be more cautionary text later in the draft , and less text in " Motivations " ? 
 Summarizing editors ' discussion : the issue here seems to be that in an interpretation of the mechanism , the client could change its behavior after receiving but before receiving an ACK - FREQUENCY frame . This should not happen ... the goal of is to negotiate future use of ACK - FREQUENCY frames . Until an ACK - FREQUENCY frame is received , an endpoint continues with RFC 9000 behavior . We will add text to this effect . does this work for you ? 
 yes , that makes sense . I will check that the picoquic code does that . 
 Works for me .
Receiving a min_ack_delay transport parameter indicates that the peer
might send ACK_FREQUENCY frames in the future.  Until an
ACK_FREQUENCY frame is received, receiving this transport parameter
does not cause the endpoint to change its acknowledgement behavior.