From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 697A921F3DC for ; Fri, 12 Jun 2015 12:55:10 -0700 (PDT) Received: from [10.134.148.52] ([80.187.106.224]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MJjOu-1Z4bUn3eMe-001Ccy; Fri, 12 Jun 2015 21:54:38 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <6AD8E150-5751-43AC-8F6C-8175C1E92DE1@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Sebastian Moeller Date: Fri, 12 Jun 2015 21:54:30 +0200 To: Jonathan Morton , Alex Elsayed Message-ID: <628F8092-841C-42DA-861B-C60C36457B04@gmx.de> X-Provags-ID: V03:K0:czeSVdAFTBTfxBuswbX7M99Qv3yDsg01+xXBtVgYwM/z1LTSjDA wXeWFPJfjtSsI/30U6g0zHWDaATY9SMP7p1AFFnXCfbAyrYzTAKCm0uTnCcqCI3NNf4o/Gf Gg8bGlHYCqm1JLk22xWE9bU0HSLJ5f/YuWqw2DtZDnsnIPlgEDZLta5y8c+ksmVnWxNs5MC E/hvwLN9TaFqD3ryzKYuQ== X-UI-Out-Filterresults: notjunk:1; Cc: bloat Subject: Re: [Bloat] Bloat done correctly? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 19:55:40 -0000 Hi Jonathan, On June 12, 2015 9:14:02 PM GMT+02:00, Jonathan Morton wrote: >We have a test in Flent which tries to exercise this case: 50 flows in >one >direction and 1 in the other, all TCP=2E Where the 50 flows are on the >narrow >side of an asymmetric link, it is possible to see just what happens >when >there isn't enough bandwidth for the acks of the single opposing flow=2E > >What I see is that acks behave like an unresponsive flow in themselves, >but >one that is reasonably tolerant to loss (more so than to delay)=2E On a >standard AQM, the many flows end up yielding to the acks; on a >flow-isolating AQM, the acks are restricted to a fair (1/51) share, but >enough of them are dropped to (eventually) let the opposing flow get >most >of the available bandwidth on its side=2E But on an FQ without AQM, acks >don't get dropped so they get delayed instead, and the opposing flow >will >be ack clocked to a limited bandwidth until the ack queue overflows=2E > >Cake ends up causing odd behaviour this way=2E I have a suspicion about >why >one of the weirder effects shows up - it has to get so aggressive about >dropping acks that the count variable for that queue wraps around=2E >Implementing saturating arithmetic there might help=2E > >There is a proposed TCP extension for ack congestion control, which >allows >the ack ratio to be varied in response to ack losses=2E This would be a >cleaner way to achieve the same effect, and would allow enabling ECN on >the >acks, but it's highly experimental=2E This is reducing the ACK-rate to make losses less likely, but at th= e same time it makes a single loss more costly, so whether this is a win de= pends on whether the sparser ACK flow has a much higher probability to pass= trough the congested link=2E I wonder what percentage of an ACK flow can b= e dropped without slowing the sender? > >- Jonathan Morton > > >------------------------------------------------------------------------ > >_______________________________________________ >Bloat mailing list >Bloat@lists=2Ebufferbloat=2Enet >https://lists=2Ebufferbloat=2Enet/listinfo/bloat --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E