Draft: draft-iyengar-quic-delayed-ack

Commentary: I think the motivations section as - is is too long . It spends a lot of time talking about what are effectively the tradeoffs . IMO the motivations section should specify why it 's useful to have the sender control the receiver 's ACK frequency , and then we can have a separate section for the tradeoffs . This takes a stab at that section , lifting things from motivations and adding some new text specifically addressing the nascent stages of a connection . I also made some editorial changes to the existing text . I am happy to add any additional considerations we think might need to be called out . This attempts to 
 Thanks for the PR , ! I like the new text you propose ( I 've proposed some changes ) , but I think you might be assuming that ACK_FREQUENCY is only used for delaying acks further . An important point that bears bringing out in the motivation is that a sender might want more frequent acks as well , for example during startup . That 's worth capturing in the modified motivation section . 
 this PR is almost done , any chance you can do another round of updates and we can get it in ? 
 sorry , I 'll do some updates today . 
 I 've updated the PR , I 'll watch and iterate on any remaining feedback quickly this time . 
 thanks Something about vim and the macbook pro keyboard apparently makes me incapable of spelling things properly . I want my desk keyboard back 
 As discussed on in the base draft , we have some confidence in a particular heuristic ( default tolerance of 2 for the first 100 packets , followed by a tolerance of 10 ) which we know to work fairly well in multiple deployments serving " typical " Internet resources to typical users . Do we want to make that recommendation explicit , or otherwise give guidance in this extension ? 
 I think it 's a good idea to describe the values for which we have experience , while encouraging experimentation . We do n't need to recommend the strategy , we just need to document it as an example strategy . 
 I think a section on considerations and maybe past experience would be very helpful . I think it 's going to be a bit of a challenge to write , but I 'm happy to take a stab if no one else wants to . 
 What I 'd want to see is just a simple explanation of what a sender could do ... I would not describe results from experience , since those are anecdotal and are going to change over time . This could be a fairly short section . 
 I can take a stab at writing something and we can go from there . 
 Thanks , ! 
 I do think the pitfalls of e.g. should be conveyed in such " cautionary " text as well . I will submit a PR this week time permitting between interop . 
 Thanks ,
A sender relies on receipt of acknowledgements to determine the
amount of data in flight and to detect losses, see QUIC-RECOVERY.
Consequently, how often a receiver sends acknowledgments dictates
how long it takes for losses to be detected at the sender.
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.
Congestion controllers that are purely window based and strictly
adherent to packet conservation, such as the one defined in QUIC-
RECOVERY, rely on receipt of acknowledgments to move the
congestion window forward and release additional data.  Such
controllers suffer performance penalties when acknowledgements are
not sent frequently enough.  On the other hand, for long-running
flows, congestion controllers that are not window-based, such as
BBR, can perform well with very few acknowledgements per RTT.
New sender startup mechanisms will need a way for the sender to
increase the frequency of acknowledgements when fine-grained
feedback is required.
As discussed in implementation, there are undesirable consequences
to congestion control and loss recovery if a receiver uniltaerally
reduces the acknowledgment frequency.  Consequently, a sender
needs the ability to express its constraints on the
acknowledgement frequency to maximize congestion controller
performance.
There are tradeoffs inherent in a sender sending an ACK_FREQUENCY
frame to the receiver.  As such it is recommended that implementers
experiment with different strategies and find those which best suit
their applications and congestion controllers.  There are, however,
noteworthy considerations when devising strategies for sending
ACK_FREQUENCY frames.
A sender relies on receipt of acknowledgements to determine the
amount of data in flight and to detect losses, e.g. when packets
experience reordering, see QUIC-RECOVERY.  Consequently, how often a
receiver sends acknowledgments determines how long it takes for
losses to be detected at the sender.
Many congestion control algorithms have a startup mechanism during
the beginning phases of a connection.  It is typical that in this
period the congestion controller will quickly increase the amount of
data in the network until it is signalled to stop.  While the
mechanism used to achieve this increase varies, acknowledgments by
the peer are generally critical during this phase to drive the
congestion controller's machinery.  A sender can send ACK_FREQUENCY
frames while its congestion controller is in this state, ensuring
that the receiver will send acknowledgments at a rate which is
optimal for the the sender's congestion controller.
Congestion controllers that are purely window-based and strictly
adherent to packet conservation, such as the one defined in QUIC-
RECOVERY, rely on receipt of acknowledgments to move the congestion
window forward and send additional data into the network.  Such
controllers will suffer degraded performance if acknowledgments are
delayed excessively.  Similarly, if these controllers rely on the
timing of peer acknowledgments (an "ACK clock"), delaying
acknowledgments will cause undesirable bursts of data into the
network.