From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B74EF3CB35 for ; Thu, 3 Jan 2019 08:20:26 -0500 (EST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1546521625; bh=1GB4hct3n/uT9VqCW9FePAMiabE103U1vyex6l1MpDo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZJ/4eIeYiNKnjPQUyqmNfTOmPnlAPMMCyX6OH8EFK9LxFYS3f0rie3nb7kRlgFQgA 7cBosdHW/+9eLPsExoL5X/YwcW2DFifMzSH3o2Sh5l0A3nrbxeEbSwwnmwLOrU9xIb EKC08EOdr5/bqPZd/LrEJkp8AE2fCwJxkwbGSNR6wEY7Y7pQ3yWCpxEQ4GcA1K8Yzf sP5Ry//5zd3xaT/8/LwpHC4IVj47PBr0ZezQrVbpHpApJeDgDg9fYHA6zzvOB2ItvZ bFc/Yiee8kJARhtYsQBTlBUd6iDbzCdBWOT2nHzZ9hsVLFN3ETisJt60iN4rd1ioBR ghGiCU8fe41HA== To: Pete Heist Cc: Jonathan Morton , Cake List In-Reply-To: References: <8F9DE6A8-8614-46A8-9E9B-7B7E4CC7414F@heistp.net> <43a8ddec5beb962c53fe828363ecc839832de2c0.camel@gmail.com> <3650A136-97A6-43F5-ADD3-B94A19775379@gmail.com> <99C93851-3539-4CB6-BED1-193B56658486@heistp.net> <87imz6xatw.fsf@toke.dk> Date: Thu, 03 Jan 2019 14:20:20 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87ftu9yj1n.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] dual-src/dsthost unfairness, only with bi-directional traffic X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 13:20:26 -0000 Pete Heist writes: >> On Jan 3, 2019, at 12:03 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >>> Jon, is there anything I can check by instrumenting the code somewhere >>> specific? >>=20 >> Is there any way you could test with a bulk UDP flow? I'm wondering >> whether this is a second-order effect where TCP ACKs are limited in a >> way that cause the imbalance? Are you using ACK compression? > > > Not using ack-filter, if that=E2=80=99s what=E2=80=99s meant by ACK compr= ession. I > thought about the TCP ACK traffic, but would be very surprised if that > amount of ACK traffic could cause that large of an imbalance, although > it=E2=80=99s worth trying to find out. > > I tried iperf3 in UDP mode, but cake is treating these flows > aggressively. I get the impression that cake penalizes flows heavily > that do not respond to congestion control signals. If I pit one 8 TCP > flows against a single UDP flow at 40mbit, the UDP flow goes into a > death spiral with increasing drops over time (iperf3 output attached). > > I=E2=80=99m not sure there=E2=80=99d be any way I can test fairness with = iperf3 in UDP > mode. We=E2=80=99d need something that has some congestion control feedba= ck, > right? Otherwise, I don=E2=80=99t think there are any rates I can choose = to > both reach saturation and not be severely punished. And if it has > congestion control feedback, it has the ACK-like traffic we=E2=80=99re tr= ying > to avoid for the test. :) Try setting cake to 'interplanetary' - that should basically turn off the AQM dropping... -Toke