From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 D65AF3B2A4 for ; Sun, 3 Mar 2019 07:53:13 -0500 (EST) Received: from hms-beagle2.lan ([77.182.35.26]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LgISa-1hNR9H2hGu-00nfnd; Sun, 03 Mar 2019 13:53:11 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: <542D3BC3-317A-4F3E-A5B6-16FF678DDFAC@gmail.com> Date: Sun, 3 Mar 2019 13:53:10 +0100 Cc: cake@lists.bufferbloat.net, Pete Heist , George Amanakis Content-Transfer-Encoding: quoted-printable Message-Id: <74291414-F44F-4795-B1E2-588C06F91151@gmx.de> 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> <542D3BC3-317A-4F3E-A5B6-16FF678DDFAC@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:qfoC7TzVUA/nMkBKz3FzMZmI+IbKI01WFdy18eeVIZ+PCS2Gzb6 32L5C9bjW9NumR9pfOxdMJz22c0Snfm2PfWn2dxJKuF/K6ztCHXTuyr0CRYCHxKxNSeHT3w +NVIdrg8j617aGriSoOgpYifc/0pvKVdEWPh3HccJuSx34QTgEP9ZrCJ7jasK+7h5jN4IOA 7+FkVmTALGas/8oJ9Vmfw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:d4Tcgy4B18w=:k68HyCcEynHpmm3DpHVZwB ksJEP0tkAJE+8XQd5kKqajnKMIMQIkaYH6RMEGHe7EALXO82TGG8ZoyMUKB7rOs6Tygmyg6GY ZLJeVwJlQYxemLjhkG2CdcZZec2l1znIhr03YXhqNFQx7lMr9znlq5bKNoqbnq9Nxt0hDzPWf OSRwt86cF38qcWuaySZ5Ru9CS3ubiFpTTn89Hf5JBQZqjLbhC4p9/LQg4Xt3/OFmqvjuXNRIi XHpWpVJUv4XL0O5J58q2/DTFdl62P3QqkSm+FwTgxnlBYRDS4bQUHRKvSyx5mQQZQi+HC548E aP01zLLHW+bBdzaiPo1H5TjTvgECZQmVmrZjN+rUMMpVFbhcMFpK7Hjiug7c4sCN3nkAgR2U6 W7ZXgt02vKHCCpyZlwC8O/NQ7g3BMjuMkoPQMipbBJEGjldKIqHb6yK2ngvI5L7qnczXb6I+3 kGwaMjtVuXjePAft9ELs9LzoG7QNH2K9Z2k3Rh82V6my+O91I73Nsk2aKfqt8CL6maNkAu67W +GcPS0UXFW6b7jlv5BXYGtZJ0978ul9qDEGj6THfIlIU+oE/Cv4moBbD1nWwVqtmtyQWhb4Be UhTta7gT8CgVz34yKFXD5z8NAzzmxcE9ovv9M66GQqfYkuP01/8pBlPqNizAeECURxUd6cBCX scgynlBv6iyjWn4xMO1H1cAATBdTooiWAEdUoHBqhn1l5kyipytHYC3bzgJYLZKCp72aJvfud u7cMdsfS/YMC81GSf/fx64smLT9ZyEraCWZ0uS26/M/OIaj7rJnli3gkSbrikTB8EH2UMOQha J0qQfFpCg2bkgGI7J/tmrNJ9yHNH0zfRmAqpGCR4vq9NTZhnG6o3m7nADrw16waFZuh3ApPtZ rfNnr3eR4S0MWDMnUPYLchrtTzuop82k/ymuaHw1dLvryh4zDJ0HhpCy7nTQoPk7bLqFujr2A FgPrf4lp0jQ== 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:53:14 -0000 > On Mar 3, 2019, at 13:13, Jonathan Morton = wrote: >=20 >> 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? >=20 > 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. Sure, it looks as if that single flow would see much less drops = than each of the 16 flows of the other IP? >=20 > 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. If the single flow gets roughly the same per-flow drops/marks as = the 16 other flows, that would be the expected behavior. Would it be = fair to assume that this looks like dual-host isolation together with = the ingress keyword results in unequal drop/mark probability based on = the IP-address isolation? >=20 > 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. >=20 > - Jonathan Morton >=20