From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 594A43B29E for ; Wed, 13 Dec 2017 07:39:58 -0500 (EST) Received: by mail-qt0-x22a.google.com with SMTP id d4so3445420qtj.5 for ; Wed, 13 Dec 2017 04:39:58 -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; bh=GkvQLC1KB9G5PXKFiRhf5U+BtOw0wtIUGQeFWZZZsAw=; b=jNs64AOi+y0ZXuHHXV/HJvRp9kx0qxTp5Asa+adnzqEsVx309/iWwOZCC7ApBpJsof kz/wuVRCGugACtmfU+MWE8O9fl1fuiXbPC268ND7jPSFSl0W+0ZC6i0/GPFQqySFHZyJ qmLZNVQb8L6bU9WDpiVMN/Vqjk/lOdp0Pif7uohEMXe9H0RbTc8Yod+TIqT2lQdMJZ5j zqFUdubVdxIL6oiYnzrXTP+9PsLrMsVZzs6Wk53kkdGzU174eiLWg8xmteoggcncWWjM lyitI6EFRo2it56dN9c1vLLJQoLuTQd8JM1Dyo67BTP871T2cdLDWeg+LG0FhGu3e9+r XpoA== 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=GkvQLC1KB9G5PXKFiRhf5U+BtOw0wtIUGQeFWZZZsAw=; b=KUe+jwzN7qBo66NjVgS/95hTWMeX/TYzbEu/dEF/y++cn+X0FCGufQ5WEtzbsgGx4E 6DPlNlneDKVf1Dfklxq3883CpuZnxh+wVn5lNpGA52+d6GAy/SsyxOnjqaAXPVwZby17 BHavNMjrpKgXXh0q82VLTyqBpzaVungtXVU+ay8HXVj/09ERRug2Z6kKH30NA8q/TJ0b fapJ6TpVMcDTERNE6g1VncGI7krH5kMdZrq5YW3PMSHo+xu3I47ej+31ChLZwt7+Qrs4 kzo1AUSPNmsPIDB4Fgi4lfRTtF+xTIsOV5DMv1N2N1FekdvElXjrXkDPXo/EHP6C3tyo zIrw== X-Gm-Message-State: AKGB3mJkAajYOD9aBvglIpgZmgM8XuBcYhOEf5wvLZqzRfMpPg8P9RT/ NDN7sWfhc9F8o2l9GFhWavfkCgIcfFl8fJl+XgE= X-Google-Smtp-Source: ACJfBov82D8eGhdEnn5n4x6jgXBbEHqdX38ucTtYpp4zyd7tKWLRko+mqTgKlw3RghxQVDxpSDh4hvd8w3THNoCzX4Y= X-Received: by 10.200.43.175 with SMTP id m44mr11015628qtm.92.1513168797778; Wed, 13 Dec 2017 04:39:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.191.227 with HTTP; Wed, 13 Dec 2017 04:39:57 -0800 (PST) In-Reply-To: References: <4D0E907C-E15D-437C-B6F7-FF348346D615@gmx.de> <019064B3-835C-4D59-BE52-9E86EE08CD02@gmx.de> From: Luca Muscariello Date: Wed, 13 Dec 2017 13:39:57 +0100 Message-ID: To: Jonathan Morton Cc: Benjamin Cronce , bloat Content-Type: multipart/alternative; boundary="001a11411c60ad4852056038101a" 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, 13 Dec 2017 12:39:58 -0000 --001a11411c60ad4852056038101a Content-Type: text/plain; charset="UTF-8" If I understand the patch well, the ack filter is actually fixing the problem of ACK compression only. Because it is enforced on packets in the queue only. It is stateless. ACK compression would happen even w/o highly asymmetric access links by just having concurrent data streams with ack streams. So, IMO, the patch is harmless per se in all cases. ACK compression is harmful though and the patch fixes it. Background on ACK compression: Lixia Zhang, Scott Shenker, and Daivd D. Clark. Observations on the dynamics of a congestion control algorithm: the effects of two-way traffic. acm sigcomm 1991. On Tue, Dec 12, 2017 at 11:03 PM, Jonathan Morton wrote: > The one "correct" argument against ack-filtering I've seen is that it > encourages (or rather validates) the use of extreme asymmetry ratios. > > However, these extreme ratios are already in widespread use without the > aid of ack-filtering. Even ADSL2 Annex A has, as its "ideal" sync rate, a > 16:1 ratio, which Annex M modifies to under 10:1. I fear we must conclude > that technical considerations are not the driving factor here. > > A better place to sort out the asymmetry problem (as well as several other > problems of current interest) would be in a free, competitive market. > Sadly such a thing is rare in the telecoms sector. > > - Jonathan Morton > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > --001a11411c60ad4852056038101a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I understand the patch well, the ack filter is actually= fixing the problem of ACK compression only.
Because it is enforced on = packets in the queue only. It is stateless.

ACK co= mpression would happen even w/o highly asymmetric access links by just=C2= =A0
having concurrent data streams with ack streams.
So, IMO, the patch is harmless per se in all=C2=A0 cases.=C2= =A0
ACK compression is harmful though and the patch fixes it.

Background on ACK compression:

Lixia Zhang, Scott Shenker, and Daivd D. Clark.=C2= =A0
Observations on the dynamics of a = congestion control algorithm: the effects of two-way traffic.=C2=A0<= /div>
acm sigcomm 1991.
<= div>=



On Tue, Dec 12, 2017 at 11:03 PM, J= onathan Morton <chromatix99@gmail.com> wrote:

The one "correct" argument= against ack-filtering I've seen is that it encourages (or rather valid= ates) the use of extreme asymmetry ratios.

However, these extreme ratios are already in widespread use = without the aid of ack-filtering.=C2=A0 Even ADSL2 Annex A has, as its &quo= t;ideal" sync rate, a 16:1 ratio, which Annex M modifies to under 10:1= .=C2=A0 I fear we must conclude that technical considerations are not the d= riving factor here.

A better place to sort out the asymmetry problem (as well as= several other problems of current interest) would be in a free, competitiv= e market.=C2=A0 Sadly such a thing is rare in the telecoms sector.

- Jonathan Morton


_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
https://lists.bufferbloat.net/listinfo/bloat

--001a11411c60ad4852056038101a--