<p dir="ltr">Taking into account a variety of scenarios, I have difficulty identifying a case where an ack deleted by a reasonably conservative algorithm would have given any practical benefit had it remained, *including* considerations of smoothness of ack-clocking.</p>
<p dir="ltr">If the uplink isn't congested then no deletions occur; if it is congested then there's a high probability that a flow-isolation scheme would deliver several acks back to back between larger data packets, so an ack-clocked sender would still be "lumpy".  That's without even considering aggregation and discrete MAC-grant links (ie. DOCSIS).</p>
<p dir="ltr">Deleting unnecessary acks from a congested uplink also frees capacity for competing traffic, which I think we can agree is a good thing when it has no deleterous side-effects.</p>
<p dir="ltr">I have not yet personally verified that the algorithm now in Cake matches my assumptions.  If it doesn't, I'll push for modifications.</p>
<p dir="ltr">Incidentally, I am of the opinion that ECE can safely be ignored for ack-filtering purposes.  Normally ECE remains set in all acks until a CWR is heard in reply, so it only matters that the ECE signal isn't *delayed* - which ack-filtering actually helps to achieve.  More sophisticated uses of ECE should also survive this as long as statistical independence is maintained.</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>