<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson <span dir="ltr"><<a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 29 Nov 2017, Luca Muscariello wrote:<br>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why does it say to do this? What benefit is there to either end system to<br>
send 35kPPS of ACKs in order to facilitate a 100 megabyte/s of TCP transfer?<br>
</blockquote>
<br></span><span class="">
Did you check RFC 3449 ?<br>
<a href="https://tools.ietf.org/html/rfc3449#section-5.2.1" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rf<wbr>c3449#section-5.2.1</a><br>
</span></blockquote>
<br>
RFC3449 is all about middleboxes doing things.<br>
<br>
I wanted to understand why TCP implementations find it necessary to send one ACK per 2xMSS at really high PPS. Especially when NIC offloads and middleboxes frequently strip out this information anyway so it never reaches the IP stack (right?).<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>I would say because it is complex to guess at which PPS to work. You would need an adaptation mechanism. Need also to change the client and the server sides. The AckCC Jonathan has mentioned </div><div>might be a solution to that.</div><div>Probably an ACK pacer in the end host, out of the TCP stack, doing Ack filtering and decimation can be simpler to implement than the proper adaptation mechanism in TCP.</div><div>Maybe inside sch_fq it would be doable. Maybe not.</div><div><br></div><div> </div></div></div></div>