From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 219333B2A4 for ; Sun, 3 Mar 2019 07:13:28 -0500 (EST) Received: by mail-lj1-x22c.google.com with SMTP id d14so1889185ljl.9 for ; Sun, 03 Mar 2019 04:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R5UCKJo/A78iU300XKv0IlJgcLDNVyGGkFThxOtZSFc=; b=I9zt3ypmXucFWFvX6k+yHK7nxtBxjjFzrar1Z+bXxawM9Y77ayrcQ9EN00y8gM19RX QKrevOg788++kkhqt/2a763UyCG7RfvYFOMZkLZmZgoX+w7vMoXWNnJD1hqKI6UV2+TZ 0WccNKaij6ui8VJ4jayJT+hQ/O/V/vkH454/F+NNdD4/REP8MEKGvJleac6MJu+vMPYu 5tAAunlCsocowSNMwNlVthbd5YOBY+zDUUtmSd4LF8XyEl/h2E5MTpM0kERqHdLPvnmj c1gus6tOxht//RewhOkSt+KFmdW1d+cubSiVTCo4D7Q6jDJjpRytmV39LL+Q5XIk0uhd xB7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R5UCKJo/A78iU300XKv0IlJgcLDNVyGGkFThxOtZSFc=; b=Av7lALra0pe37ooL5br1eQMEAe0S+jUF1BekJ6fFrLQ/5OAZzDGyW/vptvtyxl3VXQ YzOCv+WHuDF0IhbWd82yZdIX+hYDEHv/dxsYN/emFXvDtFcD4hY9/85xjGBD0pMWnByR bEiNGXcyuRlHO+B3t9j/AWrWIy2KC9MiERBMqK7AuPaSJ6YNK0hk9Kvg7VMS+iRzTfJ2 GW27BCkUrA+cWQbXxPgKLAvsAa7Yhhc6ve+yg4Y/q7r9aZfP8Wqnxdih3q1Og6M0bqY4 Wlwav6OALsoZ/tp5PLA1tAtEZ6Y2FW0Xu1BjMBoCq00E8FavS0TNcyOYvbu0I3piu+zU NITw== X-Gm-Message-State: APjAAAX53BxL+2EWYc0Ll0o8SDartjLFmHAveghP2KfW5HX2IHJLdWum N5SIKKkrn2wU6dGqKgNSHjo= X-Google-Smtp-Source: APXvYqxG8gS6s2dJu1ALuTWQi4tj7Y7hrn0UKyT2IKSeaYUdFeyvvPugKJg+Ql6fAhzudQOp4A9vsA== X-Received: by 2002:a2e:4285:: with SMTP id h5mr7880230ljf.32.1551615206996; Sun, 03 Mar 2019 04:13:26 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-234-216-nat-p.elisa-mobile.fi. [83.245.234.216]) by smtp.gmail.com with ESMTPSA id w30sm873610ljd.65.2019.03.03.04.13.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Mar 2019 04:13:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: <49A8FB42-EC0B-41B7-8CE4-888DF3C2A88D@gmx.de> Date: Sun, 3 Mar 2019 14:13:24 +0200 Cc: cake@lists.bufferbloat.net, Pete Heist , George Amanakis Content-Transfer-Encoding: quoted-printable Message-Id: <542D3BC3-317A-4F3E-A5B6-16FF678DDFAC@gmail.com> References: <72193310-7502-47B8-9554-7F8F9FA23204@heistp.net> <874l8mn9iy.fsf@toke.dk> <417E17B2-17F7-4106-A92D-C5B5AC41D808@gmx.de> <5CC769AC-AD0C-40E8-BFCA-6AD2A8162FFC@gmail.com> <49A8FB42-EC0B-41B7-8CE4-888DF3C2A88D@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Cake] Upstream submission of dual-mode fairness patch 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: Sun, 03 Mar 2019 12:13:28 -0000 > On 3 Mar, 2019, at 1:26 pm, Sebastian Moeller wrote: >=20 >>> Doesn't this look like ingress magic being applied selectively to = the users based on number of flows? I thought that the idea behind the = ingress keyword is to effectively shape harder the more bulk flows are = coming in.=20 >>=20 >> No, it simply counts dropped packets against the shaper, as well as = those actually transmitted. =20 >=20 > Sure, but the question is how is the resulting "pressure" to drop/mark = distributed over the existing (bulk) flows. >=20 >> There shouldn't be that many packets being dropped to make this much = of a difference. >=20 > My intuition (probably wrong) is that is not the few packets dropped, = but the fact that the the dropping does seem to be restricted to the = flows of the IP with more flows, no? As long as there is a backoff response to a dropped packet, the extra = back-pressure should be contained to the flows experiencing drops, and = other flows should see no difference - so you should see a slight = reduction in goodput on the 16 flows, but *no increase* on the single = flow in parallel. Even if that were not the case, the single flow should take longer on = average to recover from a cwnd reduction (even in CUBIC) to the fair = BDP. That should result in a greater reduction in goodput on the single = flow than the many flows - but we see the reverse here. So I'm not entirely sure what's happening here, but at least the = asymmetry isn't too bad; it's achieving significantly better = host-fairness than a pure flow-fair system would. - Jonathan Morton