From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 BC0243BA8E for ; Wed, 18 Apr 2018 13:11:38 -0400 (EDT) Received: from [192.168.42.133] ([79.192.248.19]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MdXSC-1enqlA3V40-00PLtj; Wed, 18 Apr 2018 19:11:37 +0200 Date: Wed, 18 Apr 2018 19:10:49 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <87vacq419h.fsf@toke.dk> <874lk9533l.fsf@toke.dk> <87604o3get.fsf@toke.dk> <578552B2-5127-451A-AFE8-93AE9BB07368@gmail.com> <87r2nc1taq.fsf@toke.dk> <0BB8B1FD-6A00-49D6-806E-794BD53A449F@gmx.de> <3457DD8E-0292-4802-BD1E-B37771DCADA2@gmail.com> <87fu3s1om2.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: cake@lists.bufferbloat.net, Georgios Amanakis , Dave Taht CC: Cake List From: Sebastian Moeller Message-ID: X-Provags-ID: V03:K1:hbwvx1R4+PHKY0XBQ6N1yTFtTbKwcrCA1+c8FdaweJ2Xb5+Tuba 2Z8q24PTWqzrl0M8sIVpkESDDUpKtmj7dIk2BSC4NLw+wCPX5GB+A+0h89qP1sBxMba9Pi/ Z9RHDG5wTt8App7mjq1VVI79G1njneTaaOcLl/7MxYxgQ1Iy0iM5JuKtg+FawCKkLSn/2CP huBQNdHCFilBF/cVUPxBA== X-UI-Out-Filterresults: notjunk:1;V01:K0:aOrDlOeIVeM=:KvkgVsmOKQ/M706dvk1NrC pHdroNjmlUN2ra32GoDghzQJ3fS0CQaaqe+ZZaFPRchLTDKFlPwLFNesW09sHXfmR1/e6UED2 jlJk8Cl24YUfp8sifLnfIXnv+lYCqqK3TsvWedey5ZlfG44nA6ytNo9f4OsFWX/ptwVPzkP0t CQrrbPStiK71lOFVoCGL0tE+Tm224AtONA4x8QvNm6fXhgbo3zWMyEyq8LlbNoQRCJ++ZJDvt DdjatndlXgvh+qdGNEn2eGb2TwU0yrl4JkxvdwAf+YZJVS5f9GDP2r3jNI9Fqkv42aP0ZSqKb VEcnLl2wv1NJAQW74ugRh/RFWJNxW1V6/NCrjVULnbRcoBi//xL2NucluP4grbiOD1xD+4pcg ZNoUWdY5BsXP8Ozhe00NvQFU6AhxQgqmfhgvP/TpYxVahDy7TyDHNsz+GOj7ubwB7qk19XV4m +cCo/4oAWG+jg7rFy7c0nnv1IGdgwNzx5REs+a8dz++7GfJQr4VNygobNYYO1+KX+6KpoYUYE APRByhw39tb7r0GrjySCOQY/5zX3iGxGQHXgKwS+14h4hYLNhYZkfcbiYpojRSTU8weQeddG2 sldeTKHgG1c2sBF0u7q7zA4+5PUFpUFVXjPVwE7P9iUb4tBy42ANpibj1G7ROEv6QvqflkozX QOzYl5xguz9JgSVOmD1S0p9gurLPHMyWofpwo9Fv4gFk+QN6G1B8M2b8Hp6cZBZtkZnkwSm2U ZcC8N8ZJ/OrmA6uRhaKeXVZZuKsvAuz22EbWUkFSmoE4X6n++JE7gNaxdnAc7OebV1yXCmDZQ bpDexz9AKc9LvQWCNi6yZ3zTZYbnhgFQk+M8DDsU03JWrMvOnM= Subject: Re: [Cake] A few puzzling Cake results 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: Wed, 18 Apr 2018 17:11:39 -0000 On April 18, 2018 6:34:47 PM GMT+02:00, Georgios Amanakis wrote: >Would making it active only for the 'ingress' mode be an option? > >Otherwise it has to be documented that when using ingress mode with >lots of >bulk flows on <20mbit/s the actual goodput is going to be less than the >set >one (eg for 9=2E8mbit/s set, 5=2E3 mbit/s actual)=2E That seems to be not the best way to think about this IMHO=2E Normal mode will restrict the gross rate of packets leaving cake while ing= ress mode tried to restrict the gross rate of incoming packets=2E The effec= t on a net measure like to/up goodput seems like it should just be a second= ary goal=2E Again, I might be off my rocker here, but I really think that c= ake should make sense on the gross rate level first=2E=2E=2E > >On Wed, Apr 18, 2018, 12:25 PM Dave Taht wrote: > >> I would like to revert this change=2E >> >> On Wed, Apr 18, 2018 at 9:11 AM, Toke H=C3=B8iland-J=C3=B8rgensen > >> wrote: >> > Jonathan Morton writes: >> > >> >>> On 18 Apr, 2018, at 6:17 pm, Sebastian Moeller >> wrote: >> >>> >> >>> Just a thought, in egress mode in the typical deployment we >expect, >> >>> the bandwidth leading into cake will be >> than the bandwidth out >of >> >>> cake, so I would argue that the package droppage might be >acceptable >> >>> on egress as there is bandwidth to "waste" while on ingress the >issue >> >>> very much is that all packets cake sees already used up parts of >the >> >>> limited transfer time on the bottleneck link and hence are more >> >>> "precious", no? Users wanting this new behavior could still use >the >> >>> ingress keyword even on egress interfaces? >> >> >> >> Broadly speaking, that should indeed counter most of the negative >> >> effects you'd expect from disabling this tweak in egress mode=2E But >it >> >> doesn't really answer the question of whether there's a compelling >> >> *positive* reason to do so=2E I want to see a use case that holds >up=2E >> > >> > What you're saying here is that you basically don't believe there >are >> > any applications where a bulk TCP flow would also want low queueing >> > latency? :) >> > >> > -Toke >> > _______________________________________________ >> > Cake mailing list >> > Cake@lists=2Ebufferbloat=2Enet >> > https://lists=2Ebufferbloat=2Enet/listinfo/cake >> >> >> >> -- >> >> Dave T=C3=A4ht >> CEO, TekLibre, LLC >> http://www=2Eteklibre=2Ecom >> Tel: 1-669-226-2619 >> _______________________________________________ >> Cake mailing list >> Cake@lists=2Ebufferbloat=2Enet >> https://lists=2Ebufferbloat=2Enet/listinfo/cake >> --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E