Draft: draft-ietf-quic-ack-frequency

Commentary: Provides more details on why excluding maxackdelay when   is used may cause premature PTOs . 
 I 'm merging this -- I think this is good , but if we need to add more cautionary text , we can still do that . 
 When the number of in - flight ack - eliciting packets is larger than the ACK - Eliciting Threshold , an endpoint can expect that the peer will not need to wait for its maxackdelay period before sending an acknowledgement . In such cases , the endpoint MAY therefore exclude the peer 's ' maxackdelay ' from its PTO calculation . Note that this optimization requires some care in implementation , since it can cause premature PTOs under packet loss when ignoreorder is enabled . Is n't this oversimplifying things so that the aspect of time until an ACK is expected to be sent is removed ? To me it is not that maxackdelay is removed completely from PTO = smoothedrtt + max(4*rttvar , kGranularity ) + maxackdelay Instead it is replaced with expected time until the sender have sent ACK - Eliciting Threshold number of packets when that is less than maxackdelay that is configured . Secondly , are you expecting the sender to make an estimate of how many packets more are received before an ACK is sent , i.e. care about what phase it is currently when calculating the PTO in regards to which packet is expected to trigger the next ACK ? However , that is clearly prone to be wrong if there is a loss occurring currently who 's loss indicating ack has not yet been received by the sender . So it appears to me that this allowance is by default creating a situation which will cause premature PTOs , and it would be better to put some restrictions on it . 
 On the second point , the sender always knows how many packets are outstanding . So , it always knows whether the PTO computation -- which is always on the latest sent packet -- should include maxackdelay or not . That said , you are right the ignoreorder causes trouble here , so how about " MAY therefore exclude the peer 's ' maxackdelay ' from its PTO calculation unless ignoreorder is enabled . When ignore_order is enabled , premature PTOs are significantly more likely under packet loss . "
When the number of in-flight ack-eliciting packets is larger than the
ACK-Eliciting Threshold, an endpoint can expect that the peer will
not need to wait for its "max_ack_delay" period before sending an
acknowledgement.  In such cases, the endpoint MAY therefore exclude
the peer's 'max_ack_delay' from its PTO calculation.  Note that this
optimization requires some care in implementation, since it can cause
premature PTOs under packet loss when "ignore_order" is enabled.
When the number of in-flight ack-eliciting packets is larger than the
ACK-Eliciting Threshold, an endpoint can expect that the peer will
not need to wait for its "max_ack_delay" period before sending an
acknowledgement.  In such cases, the endpoint MAY therefore exclude
the peer's 'max_ack_delay' from its PTO calculation.  When Ignore
Order is enabled and loss causes the peer to not receive enough
packets to trigger an immediate acknowledgement, the receiver will
wait 'max_ack_delay', increasing the chances of a premature PTO.
Therefore, if Ignore Order is enabled, the PTO MUST be larger than
the peer's 'max_ack_delay'.