On 10/8/15, 3:27 PM, "Joe Touch" <[email protected]> wrote: >CC'ing TCPM on my responses to this thread... > >On 10/7/2015 8:50 AM, Francini, Andrea (Andrea) wrote: >> How about the effect of ACK suppression on the growth of the >> congestion window, for TCP sources where the trigger for window growth >> is the arrival of an ACK, not the number of bytes it acknowledges? >> >> The Appropriate Byte Counting (ABC) option >> (https://tools.ietf.org/html/rfc3465) was addressing a similar issue >> with delayed ACKs, but it looks like it is no longer available in Linux >> (http://www.spinics.net/lists/netdev/msg225164.html). > >Even with ABC, killing off some of the ACKs would result in sender >bursts because you're interfering with ACK clocking -- unless ABC were >coupled with some sort of rate pacing. > >Note also that when you kill off intermediate ACKs you're increasing the >round-trip delay. The sender can't start sending what you ACK until the >ACK arrives; if you kill off earlier ACKs, then the later ACK will (by >definition) arrive later.
As discussed previously in this thread, the specific case where this has been deployed does not suffer from these problems. > >This is bad on many levels. > >Joe _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
