From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 4D5CA3CB35 for ; Thu, 3 Jan 2019 13:25:10 -0500 (EST) Received: by mail-lj1-x22b.google.com with SMTP id s5-v6so30448322ljd.12 for ; Thu, 03 Jan 2019 10:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=enjNqaIRDkQ2dlEY2vEL604UoKiOinfvGociSW3vqCs=; b=Iv3WoIMywOx/DBT37ujaVtxuwIwvH4cpoSogSRPDZyhWumfWJglPwgsnFmlyDB1gkk Yaz8orCsDTMw5/JZ5O73dXpq8S+d4UjUyUXvHhQ9T6cPQiQCupsPnI3KBbFou42OBNgN 6eHWCxrKyrAGx5YCepctlUGJRQv6N+LfIMvsBygNUbEtSJwcBedAU2er5lI2BEf3WD5H ajzAKfTHEY3rTa6RMjDtt2rKMiOw0HShYk2bdBINHKCnJo/VTZcVelqLgwMnUQIDQdSi BKVAOEhhyFFK/k+Fn0ARqgtS+ubHyPZjCcx0RVEHXXXl7yTdQnhhQe+Z8LG0lp8VHIpB 97+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=enjNqaIRDkQ2dlEY2vEL604UoKiOinfvGociSW3vqCs=; b=DpsOAIV8lBOPAzxVizK96P4e41bTwjxXIZ1hY3x8762sewBGPK3HJW3sFbCDTUGOBG EdZHXa4llzNxbHazPNQqDAl1fskRbO8tl9SlleBtvHtlPFft5MV0gL8/fMmt1MVyVv7/ 74KUJg9VPw1LHeYWPEZimyQeiJcO4XWcJkLQ8Cubsg6tV6DMJYfIaOhfdFA7XpQ2Woww hWu7/X/MIom+hjnQ/GEzVpT7tZ+dBxDuPvS3zeCF2CdbQvLx6kUroCGQiPo1blE2uSXL SaWx3OO1+UKKkYgWyT4uxGgECGhbB3FjG8AyIa3bhxu94ChoDnZQoqMli5y3JcgmDr+S INSw== X-Gm-Message-State: AA+aEWYYOv9T66ngavf8u3Uen53IIubtDNZnYCJznwctXjQ93psR+6Et +5AEPzvLfsEsgw98+cxUdeDPG6PWi850goFjOIk= X-Google-Smtp-Source: AFSGD/Vu5nKnYsHKzf1MRVAzfufIOtSH8hwXb9ksdS+ijNVIlX9bMkMy3peJmRuWiwbFQ5k24wEmVCy4nRFFWq/N050= X-Received: by 2002:a2e:9cd2:: with SMTP id g18-v6mr30179803ljj.161.1546539908887; Thu, 03 Jan 2019 10:25:08 -0800 (PST) MIME-Version: 1.0 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> <87ftu9yj1n.fsf@toke.dk> <316524A2-FEB5-46DC-AC96-4E1AED27695A@heistp.net> In-Reply-To: <316524A2-FEB5-46DC-AC96-4E1AED27695A@heistp.net> From: Georgios Amanakis Date: Thu, 3 Jan 2019 13:24:57 -0500 Message-ID: To: Pete Heist , Jonathan Morton Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Cake List 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 18:25:10 -0000 In my previous test the clients communicated to different flent servers (flent-newark, flent-newark.bufferbloat.net). Iproute2 was iproute2-ss4.18.0-4-openwrt. I will try to test on latest 4.20, will take some time though. I have the feeling we have discussed a similar issue in the past (https://lists.bufferbloat.net/pipermail/cake/2017-November/002985.html). I understand what Jonathan says. However I cannot explain why *without* bidirectional traffic the "dual- host" mode behaves like "src/dst-host", but *with* bidirectional traffic it behaves like "triple-isolate". The cake instances on the two interfaces are separate, right? So what happens on one interface should not influence the other. Even with bidirectional traffic the "dual- host" mode should still behave like the "src/dst-host" mode in terms of host fairness, or not? At least this is what I would intuitively expect. On Thu, Jan 3, 2019 at 11:35 AM Pete Heist wrote: > > > > On Jan 3, 2019, at 2:20 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > > > Pete Heist writes: > > > >> I=E2=80=99m not sure there=E2=80=99d be any way I can test fairness wi= th iperf3 in UDP > >> mode. We=E2=80=99d need something that has some congestion control fee= dback, > >> right? Otherwise, I don=E2=80=99t think there are any rates I can choo= se 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= trying > >> to avoid for the test. :) > > > > Try setting cake to 'interplanetary' - that should basically turn off > > the AQM dropping... > > Ok, so long as we know that we=E2=80=99re not testing any possible intera= ctions between AQM and host fairness, but we may learn more from it anyway.= I=E2=80=99m using my client to server rig here (two APU2s on kernel 4.9.0-= 8), not the APU1 one-armed router middle box. > > So, basic single client rig tests (OK): > > IP1 8-flow TCP up: 95.8 > IP2 1-flow 48mbit UDP up: 48.0 (0% loss) > IP1 8-flow x 6mbit/flow =3D 48mbit UDP down: 48.0 (0% loss) > IP2 1-flow TCP down: 96.0 > > Competition up (OK): > > IP1 8-flow TCP up: 59.5 > IP2 1-flow 48mbit UDP up: 36.7 (0% loss) > Note: I don=E2=80=99t know why the UDP send rate slowed d= own here. It=E2=80=99s probably not the CPU, as it occurs at lower rates al= so. I=E2=80=99ll forge on. > > Competition down (not OK, high UDP loss): > > IP1 1-flow TCP down: 53.3 > IP2 8-flow x 6mbit/flow 48mbit UDP down: 8.6 (82% loss) > Note: I have no idea what happened with the UDP loss rate= here, so I=E2=80=99ll go back to a single IP1 UDP test. > > Back to single client (weird, still seeing loss): > > IP2 8-flow x 6mbit/flow 48mbit UDP down: 48.0 (5.6% loss) > > Ok, I know that was working with no loss before. Stop and restart cake, t= hen (loss stops after restart): > > IP2 8-flow x 6mbit/flow 48mbit UDP down: 48.0 (0% loss) > > That=E2=80=99s better, now stop and restart cake and try the "competition= down" test again (second trial): > > IP1 1-flow TCP down: 55.3 > IP2 8-flow x 6mbit/flow 48mbit UDP down: 5.8 (88% loss) > Note: I have no idea what happened with the UDP loss rate= here, so I=E2=80=99ll go back to a single IP1 UDP test. > > Since this rig hasn=E2=80=99t passed the two-host uni-directional test be= cause of the high loss rate on the =E2=80=9Ccompetition down=E2=80=9D test,= I=E2=80=99m not going to go any further. I=E2=80=99ll rather go back to my= one-armed router rig and send those results in a separate email. > > However, I consider it strange that I still see UDP loss after the "compe= tition down=E2=80=9D test has run and is completed, then it stops happening= after restarting cake. That=E2=80=99s another issue I don=E2=80=99t have t= ime to explore at the moment, unless someone has a good idea of what=E2=80= =99s going on there. > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake