On Wed, Nov 29, 2017 at 10:21 AM, Juliusz Chroboczek <j...@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 > >> In the TCP implementations I tcpdump regularily, it seems they send one >> ACK per 2 downstream packets. > > That's the delack algorithm. One of the stupidest algorithms I've had the > displeasure of looking at (a fixed 500ms timeout, sheesh). Nagle would probably agree. He once told me he wished for 1 ack per data packet... We were young then. > > And yes, it breaks Nagle. > >> I don't want middle boxes making "smart" decisions Ironically, it was dave reed's (co-author of the end to end argument) 50x1 ratio network connection that was an impetus to look harder at this, and what I modeled in http://blog.cerowrt.org/post/ack_filtering/ (I note there is discussion and way more tests landing on the cake mailing list) The astounding number was that we were able to drop 70% of all packets (and 90+% of acks) without doing any visible harm on the tests. > > I agree, especially if they use transport-layer data to make their > decisions. I'm not particularly fond of the idea myself! But I didn't invent severe network asymmetry, or cpus that can't context switch worth a damn. >> Since this ACK reduction is done on probably hundreds of millions of >> fixed-line subscriber lines today, What I'd started with was wanting to create impairments for netem that matched common ack-filtering schemes in the field already. > what arguments do designers of TCP have >> to keep sending one ACK per 2 received TCP packets? this would be a good list to have. I note osx does stretch acks by default. > > I think it's about growing the TCP congestion window fast enough. Recall > that that AIMD counts received ACKs, not ACKed bytes. the cake code has a specific optimization to preserve slow start. It can be improved. > > (And not breaking Nagle.) > > -- Juliusz -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat