From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 C5FD63B29E for ; Mon, 4 Dec 2017 09:38:33 -0500 (EST) Received: by mail-it0-x235.google.com with SMTP id 68so7077733ite.4 for ; Mon, 04 Dec 2017 06:38:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Df3yW4YXcJm9jd2iD0AvJbTRrw1NP61hxWws0WQV+Qo=; b=hhSBDyYicZ457d/d8vlMnmseEGQacU6d7Uo2iD4RZ7OuMnS5s8qmIl864+2CejaGBA wLPsDYwPVuYz33Ixn2+x54UkJsYXWnJtS8Ev2wloyB+TmZV1+G+QeVTyvgIEoUjG6gYm 7zdTzxPDzRjU0Kg1ax2W1ggCRzSYgIF/tt7EdYfejGBrJihC4KqdeWJZdWGKX/Si4efl 3racpDoyhpk0dpUsV5CmFDuxVqn3WCQdv4iuYr7ZDBDwbRWE9b40scXGKvM3PArmU58W MoHmHDt2mCBDLPKrNQyTD6UR6w2ix27nRIpXqB2XQPcLxEpdTvzTK6+QfgQaUH7urwli 8azQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Df3yW4YXcJm9jd2iD0AvJbTRrw1NP61hxWws0WQV+Qo=; b=aXzkWxKZgtBuYcdTyCvj3Lno+quDC9WM9mSc71JwsldP1aVNf15cZ7sNSrGjtjA+CC qudJyFNi8akyW+NYkx3ZbmVkllb1Hc+wKup2PuOKsTRD5DxKB+2krLan1rxtdt7krypb 53P2jPIzQaOhB/82F4KNDqRzbtqqJDo2lcxQvczgzMyXNb64k5qs94tWci2Khu0DOQAW WWCqiyQ6Z9QNqXw6Jwj7pEIZ4ikg3lTz7f+3vhDYrsqDU32kplJeXRu4Taz4BrZ4+4V6 GVcUyCMCWYMa0HyoPjClW2UfgbyNqxaMgL1Kj9MwQobQJcs5yUXRPOH8f4Vm/ZSXgPnL 903g== X-Gm-Message-State: AKGB3mLDWMWnG/2LflVi204PC3z2F93bSKmQk7k/aG4mUoNHbdJVNZHV SGRvVavn8s1ewLmtvzGLkvM= X-Google-Smtp-Source: AGs4zMZEa1hOJsMMzmTxJt+PiB0e6IqIwhJgQIHuvSf1xbtqm1U1Qm6krcEB+J1U5BbHLTQtyp6jeg== X-Received: by 10.36.115.133 with SMTP id y127mr5005620itb.83.1512398313282; Mon, 04 Dec 2017 06:38:33 -0800 (PST) Received: from [172.22.8.150] ([75.98.196.98]) by smtp.gmail.com with ESMTPSA id b195sm6345484ioa.43.2017.12.04.06.38.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Dec 2017 06:38:31 -0800 (PST) Reply-To: davecb@spamcop.net To: bloat@lists.bufferbloat.net References: <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> <87fu8rf97o.fsf@nemesis.taht.net> From: David Collier-Brown Message-ID: Date: Mon, 4 Dec 2017 09:38:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <87fu8rf97o.fsf@nemesis.taht.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: Mon, 04 Dec 2017 14:38:33 -0000 On 03/12/17 10:44 PM, Dave Taht wrote: > More generally, the case where you have a queue containing acks, stored > up for whatever reason (congestion, media access, asymmetry), is a > chance for a middlebox or host to do something "smarter" to thin them > out. > > Acks don't respond to conventional congestion control mechanisms anyway. > > There is another case (that I don't support) where you would try to > filter out acks on the fly without a queue (similar to how a policer > works). The flaws of this approach are many, including tail loss, > which the concept of filtering down (reducing?) a queue, doesn't have. Taking a very high-level view of this discussion, the times you want to change a protocol or add a 'network optimizer" are when enough time has passed that the original requirements don't describe what you want any more. In a previous life I did some work on the optimization (by remote proxying) of the SMB protocol used by Samba. It was very desirable, but at the cost of continuing to support a protocol that did the wrong thing, and kludging it with additional middleware.  In effect, making your new system dependent on a bug in the old one. Eventually we said the heck with it, and sat Samba on top of a different protocol entirely, one which worked well over non-local links. That concentrate the impedance matching in Samba, not in code I had to maintain in synchronization with a bug (;-)) --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain