From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x22c.google.com (mail-vn0-x22c.google.com [IPv6:2607:f8b0:400c:c0f::22c]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 87A5921F3AA for ; Fri, 12 Jun 2015 12:14:04 -0700 (PDT) Received: by vnbf7 with SMTP id f7so7510256vnb.7 for ; Fri, 12 Jun 2015 12:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=it/dGT8Gr0y7vsrrRDCmgTbGxOhtwYGVSmnK5EqDbQs=; b=aBwp8Jc09apcRlD6ep1DhgZCZdLnvD6BrXsjkl3KlLKFRTjKdOhUk8Q7rU4dH2sDTS /xPEFNhGVhZaaH3AVOR/oSN5OTy95377Mqcxtujq8dSiggVxHGgCaKglD9qNa7RPPaxN +D0T8eNz52V+q4Ba/Url/G/zi5VuW8a3eLxFRDvfr7weogp6a/wGsjZK7bJZrgLQDVDU wX0kF9hbX/WJ12zT3sm3t7TrRPY7byYLGQ779wvkAduTxH6YUSMo2xSeRq4D9xgcQiAE EQLpayD64kDMVfH5m8xYeTm8CbXsRP347bDEEjmiRoteg8+eGdXRSM2XpuxBSokAp/N1 YiMw== MIME-Version: 1.0 X-Received: by 10.52.136.9 with SMTP id pw9mr19501196vdb.44.1434136442923; Fri, 12 Jun 2015 12:14:02 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Fri, 12 Jun 2015 12:14:02 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Fri, 12 Jun 2015 12:14:02 -0700 (PDT) In-Reply-To: References: <6AD8E150-5751-43AC-8F6C-8175C1E92DE1@gmx.de> Date: Fri, 12 Jun 2015 22:14:02 +0300 Message-ID: From: Jonathan Morton To: Alex Elsayed Content-Type: multipart/alternative; boundary=bcaec52e658b3d6e8b051856e9d8 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:14:32 -0000 --bcaec52e658b3d6e8b051856e9d8 Content-Type: text/plain; charset=UTF-8 We have a test in Flent which tries to exercise this case: 50 flows in one direction and 1 in the other, all TCP. 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. 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). 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. 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. Cake ends up causing odd behaviour this way. 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. Implementing saturating arithmetic there might help. There is a proposed TCP extension for ack congestion control, which allows the ack ratio to be varied in response to ack losses. This would be a cleaner way to achieve the same effect, and would allow enabling ECN on the acks, but it's highly experimental. - Jonathan Morton --bcaec52e658b3d6e8b051856e9d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

We have a test in Flent which tries to exercise this case: 5= 0 flows in one direction and 1 in the other, all TCP. Where the 50 flows ar= e 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 o= pposing flow.

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 de= lay). On a standard AQM, the many flows end up yielding to the acks; on a f= low-isolating AQM, the acks are restricted to a fair (1/51) share, but enou= gh of them are dropped to (eventually) let the opposing flow get most of th= e available bandwidth on its side. 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.

Cake ends up causing odd behaviour this way. I have a suspic= ion about why one of the weirder effects shows up - it has to get so aggres= sive about dropping acks that the count variable for that queue wraps aroun= d. Implementing saturating arithmetic there might help.

There is a proposed TCP extension for ack congestion control= , which allows the ack ratio to be varied in response to ack losses. This w= ould be a cleaner way to achieve the same effect, and would allow enabling = ECN on the acks, but it's highly experimental.

- Jonathan Morton

--bcaec52e658b3d6e8b051856e9d8--