On Thu, Oct 8, 2015 at 2:31 PM, David Lang <[email protected]> wrote: > On Thu, 8 Oct 2015, Joe Touch wrote: > > On 10/7/2015 12:42 AM, LAUTENSCHLAEGER, Wolfram (Wolfram) wrote: >> ... >> >>> Is this topic addressed in some RFC already? >>> >> >> It's a direct violation of RFC793, which expects one ACK for every two >> segments: >> >> 4.2 Generating Acknowledgments >> >> The delayed ACK algorithm specified in [Bra89] SHOULD be used by a >> TCP receiver. When used, a TCP receiver MUST NOT excessively delay >> acknowledgments. Specifically, an ACK SHOULD be generated for at >> least every second full-sized segment, and MUST be generated within >> 500 ms of the arrival of the first unacknowledged packet. >> > > actually, this is only a violation of the SHOULD section, not the MUST > section. > > And if the Ack packets are going to arrive at wire-speed anyway (due to > other causes), is there really an advantage to having 32 ack packets > arriving one after the other instead of making it so that the first ack > packet (which arrives at the same time) can ack everything?
I would like to add that GRO also cause stretched ACKs (acking up to 64KB), and GRO is crucial to reduce cycles for +10Gbps transfers on some architectures. > And if there is such an advantage, does it outweight the disadvantages > that the extra ack packets cause by causing highly asymmetric links to be > overloaded and drop packets? > > David Lang > > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm >
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
