Re: [Bloat] benefits of ack filtering

[Dave Taht <dave.taht@gmail.com>]

On Wed, Nov 29, 2017 at 11:03 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
> Hi Bloaters,
>
> I’d like to give offer some information and thoughts on AckCC, at the bottom
> of this email.
>
>
> On Nov 29, 2017, at 4:53 PM, Luca Muscariello <luca.muscariello@gmail.com>
> wrote:
>
>
>
> On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson <swmike@swm.pp.se>
> wrote:
>>
>> On Wed, 29 Nov 2017, Luca Muscariello wrote:
>>
>>>> Why does it say to do this? What benefit is there to either end system
>>>> to
>>>> send 35kPPS of ACKs in order to facilitate a 100 megabyte/s of TCP
>>>> transfer?
>>>
>>>
>>> Did you check RFC 3449 ?
>>> https://tools.ietf.org/html/rfc3449#section-5.2.1
>>
>>
>> RFC3449 is all about middleboxes doing things.
>>
>> 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?).
>>
>
> 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
> might be a solution to that.
> 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.
> Maybe inside sch_fq it would be doable. Maybe not.
>
>
> I’m adding the response from Jonathan Morton here to make this more
> self-contained:
> ***
> 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.
>
> That would be perfectly sufficient.
>
> - Jonathan Morton
>
> ***
>
> 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:
> http://heim.ifi.uio.no/michawe/teaching/dipls/marius-olsen/mastersthesis-mariusno.pdf
> and his code is here: http://folk.uio.no/mariusno/master/
>
> 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?”
> - 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.
>
> Interestingly, at IETF 98, not so long ago, Ingemar Johansson explained to
> folks at TSVWG that the problem IS real:
> https://datatracker.ietf.org/meeting/98/materials/slides-98-tsvwg-sessb-7-transport-protocol-feedback-overhead-issues-and-solutions/
>
> So, let me now try to answer “why is TCP not doing that?”.
> - First, AFAIK, AckCC isn’t implemented anywhere  (except that we have this
> old patch - please feel free to download, adapt, and play with it !!)
> - 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.
> - 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.
>
> 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?!
>
> 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.
> 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,

Nor one Linux.

>2) ACKs are still quite
> important in Fast Recovery,

If you are already achieving twice the rate, what does occasionally
losing fast recovery cost?

>3) BBR might not need to clock out ACKs, but it
> measures their incoming rate.

 if it collapses to a punctuated paced source, it could also notice
acks being lost, and extrapolate.

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

I'm not a huge fan of slow start in IW10.

And: Strike "unnecessarily is", and substitute "may not be", as
http://blog.cerowrt.org/flent/ack_filter/1Gbit-20Mbit-rrul_be.png
seems to show. The ack-filter result shows one flow growing rapidly,
and three others not.


> 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.
>
> 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.
>
> Just some thoughts, and some context.
>
> Cheers,
> Michael
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619