<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Bloaters,<div class=""><br class=""></div><div class="">I’d like to give offer some information and thoughts on AckCC, at the bottom of this email.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 29, 2017, at 4:53 PM, Luca Muscariello <<a href="mailto:luca.muscariello@gmail.com" class="">luca.muscariello@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson <span dir="ltr" class=""><<a href="mailto:swmike@swm.pp.se" target="_blank" class="">swmike@swm.pp.se</a>></span> wrote:<br class=""><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 class="">
<br class="">
</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 class="">
send 35kPPS of ACKs in order to facilitate a 100 megabyte/s of TCP transfer?<br class="">
</blockquote>
<br class=""></span><span class="">
Did you check RFC 3449 ?<br class="">
<a href="https://tools.ietf.org/html/rfc3449#section-5.2.1" rel="noreferrer" target="_blank" class="">https://tools.ietf.org/html/rf<wbr class="">c3449#section-5.2.1</a><br class="">
</span></blockquote>
<br class="">
RFC3449 is all about middleboxes doing things.<br class="">
<br class="">
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 class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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 class="">might be a solution to that.</div><div class="">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 class="">Maybe inside sch_fq it would be doable. Maybe not.</div></div></div></div></div></blockquote><div><br class=""></div><div>I’m adding the response from Jonathan Morton here to make this more self-contained:</div><div>***</div><div>Given an RTT estimate and knowledge of the congestion window, the AckCC option could be used to target a handful of acks (maybe 4 to 10) per RTT. As usual, extra acks would be sent when loss is suspected, on ECN events, and when the push flag is set.</div><div><p dir="ltr" class="">That would be perfectly sufficient.</p><p dir="ltr" class="">- Jonathan Morton</p><div class=""><div>***</div></div><div class=""><br class=""></div><div class="">A few years ago, David Ros, whom I’m adding in cc, one of the original authors of RFC 5690 did a sabbatical with me at the University of Oslo. As part of that, we advised a master student to carry out tests with AckCC, and analyze the RFC to understand how it would have to change if we were to proceed to Proposed Standard. The result of his investigation is here:</div><div class=""><a href="http://heim.ifi.uio.no/michawe/teaching/dipls/marius-olsen/mastersthesis-mariusno.pdf" class="">http://heim.ifi.uio.no/michawe/teaching/dipls/marius-olsen/mastersthesis-mariusno.pdf</a></div><div class="">and his code is here: <a href="http://folk.uio.no/mariusno/master/" class="">http://folk.uio.no/mariusno/master/</a></div><div class=""><br class=""></div><div class="">Now, after finishing the thesis, when it came to writing a paper about it, we got stuck in the discussion of “how are we going to explain that this is really necessary?”</div><div class="">- we didn’t want to submit a “solution searching for a problem” paper and didn’t want to get rejected for not having shown that the problem truly exists. Searching for this a little in the academic world (papers) gave us no result, at least back then.</div><div class=""><br class=""></div><div class="">Interestingly, at IETF 98, not so long ago, Ingemar Johansson explained to folks at TSVWG that the problem IS real:</div><div class=""><a href="https://datatracker.ietf.org/meeting/98/materials/slides-98-tsvwg-sessb-7-transport-protocol-feedback-overhead-issues-and-solutions/" class="">https://datatracker.ietf.org/meeting/98/materials/slides-98-tsvwg-sessb-7-transport-protocol-feedback-overhead-issues-and-solutions/</a></div><div class=""><br class=""></div><div class="">So, let me now try to answer “why is TCP not doing that?”.</div><div class="">- First, AFAIK, AckCC isn’t implemented anywhere (except that we have this old patch - please feel free to download, adapt, and play with it !!)</div><div class="">- Second, if someone was to update TCP to support this, a bit more than simple statements about the amount of traffic being large would be good IMO - I mean, some convincing proof that the large number of ACKs *really* is a problem.</div><div class="">- Third, once this is implemented and deployed and found to be beneficial, it would be useful to follow up in the IETF and update RFC 5690.</div><div class=""><br class=""></div><div class="">Since nobody seems to be doing any of these things, nothing changes. But consider this: I see folks from Google doing a lot of TCP updates in the IETF for which they themselves appear to have an immediate need. Given the heterogeneity and magnitude of traffic produced by Google, if they don’t see a pressing need for it, I suspect that, indeed, the problem might not be so real after all?!</div><div class=""><br class=""></div><div class="">Also, a word of caution. In this thread, there seems to be general agreement that TCP sends way too many ACKs, and that reducing that number would be fantastic.</div><div class="">I’m not so convinced. Okay, even if TCP isn’t that ACK-clocked anymore in Linux: 1) there isn’t only Linux in this world, 2) ACKs are still quite important in Fast Recovery, 3) BBR might not need to clock out ACKs, but it measures their incoming rate. For another example, consider a non-BBR sender in slow start: without ABC, missing ACKs would let it grow its cwnd too cautiously. Thanks to ABC, this can be done more aggressively - but ABC recommends a limit on how quickly to “jump” in the rate in response to a single ACK, for good reason - to avoid producing even heavier bursts. But with this limit, again, the TCP sender is unnecessarily cautious in Slow Start just because it misses ACKs.</div><div class=""><br class=""></div><div class="">My point is: the ACKs ARE the feedback that TCP works on; when you take them away, TCP becomes “blind”, and whatever improvement is made to TCP will have to be developed on that basis.</div><div class=""><br class=""></div><div class="">I’m not saying that 1 ACK for every two packets is really necessary… but unless there’s hard proof that this really is a problem, I’d caution against a “downward spiral” here: the level of asymmetry offered to users today is probably somehow related to the commonly seen TCP ACK rate - so if TCP starts to reduce the ACK rate, folks may decide to make links even more asymmetric, etc. etc. … I’m not sure this is a good direction.</div><div class=""><br class=""></div><div class="">Just some thoughts, and some context.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Michael</div><div class=""><br class=""></div></div></div></div></body></html>