From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (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 E35B63B2A4 for ; Sun, 3 Dec 2017 09:09:33 -0500 (EST) Received: by mail-pl0-x235.google.com with SMTP id 1so8926132pla.7 for ; Sun, 03 Dec 2017 06:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mounce.com.au; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yjozpf8W67hvszZgyc6PODsarbv2O0Qo3F9VfHnsKV0=; b=nIZ22aPwMFwvaDsQXEZc/0SjuL2vir8YNoR9Gk5jPUewnLudYS8ggjqHH8rdr2O1Yp CbE/MUvFlbsKzFuboFlj3iIv+gSJjhiQ7IOZeEoP7shcMD0gdZ4af/QYmpxpTZzbvoRa uyEAMghUsQb7eqZfNf2l/AHqsMR2n7GMJ1c73ozh4+0G8HxynydOdb+7ryBOpiRvd+iz bdScOYMZu80H6invmxe9frVhCslE1xoSX2wen7ciM8ukMJ3k8YLF/RX0F/EtdY/kS/gr IeNWVTz7BB8fpYmBsRwYyykSgFBDRhURcvNW5eG6RlyL3lbrx0zTuHlj70725shPpoQ2 09iw== 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; bh=Yjozpf8W67hvszZgyc6PODsarbv2O0Qo3F9VfHnsKV0=; b=Dch+NAzUIyEfPym2L0DpRXil6tnUvof8Rpqtj8lED7imAieu7dSZUXUAiFFd6RW4aV wA43jFk65FCEq8gVuaDl+1ESZIQqBOXUuQZ2ZCV1oErs5QucUWYiTG0HUqpe6x+u+tYG ZrpSuHvJu+PaQ0NoJ2KrgXg00mhkF2IZ6m0CJfKz4m93E+1cZouoANbBXOyMesDsyQhv WITLwRE+Yte/8hIfCiPckAt8Jt96CdbSNc7vchNu2+jUji/Vmrzh5rFomRNbCtJjKxdB ywL0JhTj6BnwHfiA9oq0Lnx9Skbm0fsw1gNpAhD4nRdpADH1lGt9RKoIj01efaEMigCv Hyhg== X-Gm-Message-State: AKGB3mIff3ks4QnYVyqbT3Z5Sinq37PFLFWzu8o2M/tRyYe6/4Wr+xch SFJ/ggyWDTaFJfxnBkygQiFG6qkwbdS3FX+AIdLBFQ== X-Google-Smtp-Source: AGs4zMZyMEloNZUBx6KIbJxA8R+pjEzQNcDdz+EW9SvHQM2F46nF0RMVieqH0mssgqd4OcC1F9cS1S+MYmEGBFrFTRk= X-Received: by 10.159.254.24 with SMTP id r24mr1857493pls.333.1512310172981; Sun, 03 Dec 2017 06:09:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.187.3 with HTTP; Sun, 3 Dec 2017 06:09:17 -0800 (PST) X-Originating-IP: [101.166.205.68] In-Reply-To: <87po7vud6q.wl-jch@irif.fr> References: <4D0E907C-E15D-437C-B6F7-FF348346D615@gmx.de> <7B92DF4D-B6B5-4A64-9E10-119DCA2D4A6F@ifi.uio.no> <1512037480.19682.10.camel@gmail.com> <6b494910-1373-afb0-5b93-99b725391fb3@gmail.com> <87wp2638yo.fsf@toke.dk> <87tvxa36sn.fsf@toke.dk> <87po7ygxai.fsf@nemesis.taht.net> <87shcui3ni.wl-jch@irif.fr> <87shcs9k0v.wl-jch@irif.fr> <87po7vud6q.wl-jch@irif.fr> From: Ryan Mounce Date: Mon, 4 Dec 2017 00:39:17 +1030 Message-ID: To: Juliusz Chroboczek Cc: Jan Ceuleers , bloat@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Subject: Re: [Bloat] [Make-wifi-fast] 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: Sun, 03 Dec 2017 14:09:34 -0000 On 4 December 2017 at 00:27, Juliusz Chroboczek wrote: >>> I'm lost here. What exact problem is the ACK hack supposed to work >>> around? Ridiculous amount of asymmetry in the last-hop WiFi link, or >>> outrageous amounts of asymmetry in a transit link beyond the last hop? > >> My understanding is that the issue that gave rise to this discussion was >> concerned with upstream bandwidth conservation in the uplink of a DOCSIS >> network by the cable modem dropping a large percentage of upstream TCP ACKs. > > Ok, that's what I thought. I'm glad we agree that WiFi is a different issue. > > A TCP Ack is 40 bytes. A data packet is up to 1500 bytes. > > As far as I know, DOCSIS has an asymmetry factor that is between 4 and 10, > depending on the deployment. With worst case asymmetry being 10, this > means that you can send an Ack for every data packet with 400 byte data > packets, every second data packet with 200 byte data packets. If the > asymmetry is a more reasonable 4, then the figures are 100 and 50 > respectively. > Many would kill for a 10:1 DOCSIS connection. 50:1 is not rare, and I have personally been subscribed to a near 100:1 service. Either way, the issue is not so much ACKs from downloads on an otherwise idle link. The real issue is when the ACKs are contending with a file upload, in this case download speeds will suffer if ACKs are naively tail-dropped. Recovering extra bandwidth for the file upload can be a happy side-effect. You're also only counting IP packet length. The DOCSIS shaper deals with ethernet frames so 58 / 1518 bytes. > Try as I might, I fail to see the problem. Are we advocating deploying > TCP-aware middleboxes, with all the problems that entails, in order to > work around a problem that doesn't exist? > > -- Juliusz > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat Regards, Ryan Mounce