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). Is there another workaround already available? Andrea -----Original Message----- From: aqm [mailto:[email protected]] On Behalf Of Steve Bauer Sent: Wednesday, October 07, 2015 7:41 AM To: LAUTENSCHLAEGER, Wolfram (Wolfram) Cc: Greg White; [email protected] Subject: Re: [aqm] TCP ACK Suppression On Wed, Oct 7, 2015 at 3:42 AM, LAUTENSCHLAEGER, Wolfram (Wolfram) <[email protected]> wrote: > Is this specialized upstream TCP ACK handling, particularly the > prioritization a general recommendation in all access technologies? > Perhaps it should be, since otherwise up and downstream TCP flows interfere > in a crazy queue oscillation that is typically misinterpreted by AQMs. > Is this topic addressed in some RFC already? See: RFC 3449: TCP Performance Implications of Network Path Asymmetry https://tools.ietf.org/html/rfc3449 in particular section 5.2 5.2 TYPE 1: Reverse Link Bandwidth Management ...................19 5.2.1 ACK Filtering ...........................................20 5.2.2 ACK Decimation ..........................................21 Steven Bauer MIT _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
