On Wed, 2017-11-29 at 15:59 -0800, Stephen Hemminger wrote: > On Wed, 29 Nov 2017 10:41:41 -0800 > Dave Taht <[email protected]> wrote: > > > On Wed, Nov 29, 2017 at 10:21 AM, Juliusz Chroboczek <[email protected]> > > 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. _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
