Re: [Cake] [Bloat] benefits of ack filtering

[Eric Dumazet <eric.dumazet@gmail.com>]

On Wed, 2017-11-29 at 15:59 -0800, Stephen Hemminger wrote:
> On Wed, 29 Nov 2017 10:41:41 -0800
> Dave Taht <dave.taht@gmail.com> wrote:
> 
> > On Wed, Nov 29, 2017 at 10:21 AM, Juliusz Chroboczek <jch@irif.fr>
> > wrote:
> > > > The better solution would of course be to have the TCP peeps
> > > > change the
> > > > way TCP works so that it sends fewer ACKs.  
> > > 
> > > Which tends to perturb the way the TCP self-clocking feedback
> > > loop works,
> > > and to break Nagle.  
> > 
> > Linux TCP is no longer particularly ack-clocked. In the post
> > pacing,
> > post sch_fq world, packets are released (currently) on a 1ms
> > schedule.
> > Support was recently released for modifying that schedule on a per
> > driver basis, which turns out to be helpful for wifi.
> > 
> > see: https://www.spinics.net/lists/netdev/msg466312.html
> 
> Also TCP BBR has lost its initial luster since it is unfair and
> ignores
> losses and ECN (see recent netdev paper).

Recent netdev paper (from Larry) mentioned that fq_codel is used.

fq_codel is stochastic, so not a fairness champion with many flows.
There is a reason we use fq [1] instead ;)

We asked Larry how to reproduce his (surprising) results, because we
suspect some setup error or bias. He has to update his github trees.

netem can be tricky to use properly.

[1] Although the choice of packet scheduler is no longer an issue with
BBR now TCP can fallback to internal pacing implementation.

About ECN : We do not enable ECN for edge communications, so BBR runs
without ECN being negotiated/accepted.

We will probably take care of this point soon, but we had more urgent
problems.