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.
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). 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. I have not yet personally verified that the algorithm now in Cake matches my assumptions. If it doesn't, I'll push for modifications. 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. - Jonathan Morton
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat