[Bloat] benefits of ack filtering

[Dave Taht]

On Wed, Nov 29, 2017 at 11:03 PM, Michael Welzl <michawe at 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 at gmail.com>
> wrote:
>
>
>
> On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson <swmike at 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, 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.

My answer to questions like this that are difficult reason about... is
to run the experiment.

Trying out BBR in the testbeds we have setup would be straightforward,
although rrul_be (which is what we have the MOS results for)  is not
the best test for BBR's behaviors.

Maybe more of a staircase test would be better.

(note we're also looking at sfq and pfifo as references)


> 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>



-- 

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