The fact that you need to do something to go fast does not make it safe for everyone else.
Again, TCP is intended to work everywhere, not to work well anywhere. Joe On 10/8/2015 2:52 PM, Yuchung Cheng wrote: > > > On Thu, Oct 8, 2015 at 2:31 PM, David Lang <[email protected] > <mailto:[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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/aqm > > _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
