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?
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
