From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CC14C3BA8E; Wed, 29 Nov 2017 13:41:42 -0500 (EST) Received: by mail-qk0-x22e.google.com with SMTP id b184so5660202qkc.13; Wed, 29 Nov 2017 10:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=G/IEEIwliKZNHZvCtyrw66+ANdSMvGAXIAQgDxzrApI=; b=hRVbrlo1mmVlMRBrWYeSTbyRDjVOzWhgC0YWZc7W5A3q14+g7jmYiE+Sr73qp0TN2+ pTBVPnGypXnaKXsnpki2NVBrfJS9rShufGdGN3yVbzDJ13gcNc2cDIkL6FGYc4Tjlfqn gLpbuh8CqmfqMiSqGbA8ihZG7wJy/KN+QPL8GRuyW2ACA3DOLbh/8V7UqvxAp9mhybzP 9FaHP/sQbhEUNm6hmk6maCqwpnFWti8k36KX+yPOQPdsZN7YefpUaAsA+sgq+xOlp3dy +5QN7SP5O15hw6T+rnMINiew3PxlXPGb1qCegqMa/UrdqNe5Gwu/cTBWerDMCAunTBB0 pbww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=G/IEEIwliKZNHZvCtyrw66+ANdSMvGAXIAQgDxzrApI=; b=rc9/cV/HB/IildYu9GSevK66K7kgzNxCGer3v3xwLGGz81kqr6wZkNtFMYfA9wE/6l epJ+jAVsQP8RRiY1UT4HzxXMf0VxwGEXoeXmzPVdLnZ7NqUF/chq1gxjoy3BEQoEDq5n 56ciifUgANTWbu4Yehta4T7KHXDQYYK02J/RGtm7nDqXUSGB2HEEWB/wMYof3webh1V2 AZTm3rSrlRLFpiVUR0l2CCPU0Egi+Ber6kbcfxuTAS6KHtKNqVkZJTyjmRKRzzmv0MEx mBJMOvvHdWfbtSUH8TZ90Ho85I+sO/lrrptEo4JKbHxqaKxJTsiqgYk7bqu/TtENjmk4 R+9Q== X-Gm-Message-State: AJaThX44X2UBlY2Vxf8HgJSESrHPABKb2yoh+AwBrCTVZ9G0sh+0SjkT iBIAZgNnL6ln6RGummv2whyQiGI2/uOyJHulpic= X-Google-Smtp-Source: AGs4zMa482sMduHnJpU5G3ZlkKi7lJ9N+Ek+QIlbGYVcHKdlVdUNgDdOR0VbpHkYMBSuENMHetRZbe0Aa1qyANK/EIA= X-Received: by 10.55.154.85 with SMTP id c82mr5934280qke.327.1511980902329; Wed, 29 Nov 2017 10:41:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.193.93 with HTTP; Wed, 29 Nov 2017 10:41:41 -0800 (PST) In-Reply-To: <7i1skhrln1.wl-jch@irif.fr> References: <7i1skhrln1.wl-jch@irif.fr> From: Dave Taht Date: Wed, 29 Nov 2017 10:41:41 -0800 Message-ID: To: Juliusz Chroboczek Cc: Mikael Abrahamsson , bloat , Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] benefits of ack filtering X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 18:41:42 -0000 On Wed, Nov 29, 2017 at 10:21 AM, Juliusz Chroboczek 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 th= e > 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 --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619