From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 32D003CB35 for ; Wed, 18 Apr 2018 11:17:16 -0400 (EDT) Received: from [192.168.250.102] ([134.76.241.253]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MEsXW-1fErUg2NGE-00Fx02; Wed, 18 Apr 2018 17:17:12 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 18 Apr 2018 17:17:11 +0200 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <0BB8B1FD-6A00-49D6-806E-794BD53A449F@gmx.de> References: <87vacq419h.fsf@toke.dk> <874lk9533l.fsf@toke.dk> <87604o3get.fsf@toke.dk> <578552B2-5127-451A-AFE8-93AE9BB07368@gmail.com> <87r2nc1taq.fsf@toke.dk> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.6.18) X-Provags-ID: V03:K1:V0pA1OGGvmaL2wYyjBo0AyFJvZUMXRBja7lk5skRSd8tYKveAp1 JqyU+0K49xTQ/gxVXJlSxoeEEpAAMLm3hsitlV0wcu2vRTphnk1T8H7opvw68IN4PyIj7B+ 6V31dgiK1cxAUhveTtj8ufRzPBBRJSZAWt+yieXebHpIzW1FSBzmxHhPnDcVGSDWceUjiVv p+CIQYYvLMsse8k0yhsvg== X-UI-Out-Filterresults: notjunk:1;V01:K0:A57mFOLd5sk=:M+CZlB6+oJZb39IoOGkYpz ieZrNgO0r2Y7l5F5L2NAzw+dDOIU3kXplPSVCjIottfVQeJ0b1+0dkY7Y7ZoRkJSP1Jh0kqJ4 KreDd46TI7l0UjUVyfr7r9fSG4fNwG+ULm9+kBtN8NOKLoq246TmCTT0HPJgXim51VGYDEnid RASOpRwEECa9oFiUGxR7oBcYeYsjN96v7jzi9rm5zKyZ3kD30wSbx3ZO59f0iq4GO2vo0VBsy uy+yGvrF520wmCH5UjlU3B6rPswId7OCXaFta0ddv8pwKRBJZxW5+WcAfs2cjdSP7ZdICQNzw 7oNh0j/qBF3aHrGw+6vUvHDlRsvA/YaMM+bCVeNS5jIyhSkADS0HXS4WWR3zDYXc+gzKRTeUZ OONkAFmUzQk/IRT49os46Hm2t/eoy9EsOogSOH54utZYm9vDdP+JYNKp1631e81/CoOLxpBgS MepEurJYeSmzjSugei+a+MH5bbTZ9lJ240ogXBiZm3wYC4Q7m0JGOVFsQ5GCWExH1BFL+6LK7 Wd1+jOp6N3zD4Ms8t1taVXUj9wc9xr23dd9eE9WfN6qXs8hxp2kVL+usmiGaphHdhJ3qsEHCL cQNLUcpgCADY4ZbyTZc0iy9E+s5dmtdMHg7bzDYQrBhoR8ILEiBhhvitBCdIZ/R46PvP2qG60 JDbV+wnQgwbonrbRNds6L5cNroEKI09Kw4HP+/zeOaXrHhzcgH9n+pYFJTvfLvdawztxCqX0f Y0DyMLi+sDBVIt2/3dPnpXLF0s/pfodlS8Tb5h2MptRF8ZM7QDrKlLquCSIE1pY3a2rdMMbMk BssnoRghpwzdsNLgS8nnD2TJ6U/2+Kmu+7Kas/nQM6by4gkWvY= 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 15:17:16 -0000 > On Apr 18, 2018, at 17:03, Jonathan Morton = wrote: > [...] >>> Without that, we can end up with very high drop rates which, in >>> ingress mode, don't actually improve congestion on the bottleneck = link >>> because TCP can't reduce its window below 4 MTUs, and it's having to >>> retransmit all the lost packets as well. That loses us a lot of >>> goodput for no good reason. >>=20 >> I can sorta, maybe, see the point of not dropping packets that won't >> cause the flow to decrease its rate *in ingress mode*. But this is = also >> enabled in egress mode, where it doesn't make sense. >=20 > I couldn't think of a good reason to switch it off in egress mode. = That would improve a metric that few people care about or can even = measure, while severely increasing packet loss and retransmissions in = some situations, which is something that people *do* care about and = measure. [...] 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? Best Regards Sebastian