From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 0E8993B2A4 for ; Thu, 26 Apr 2018 11:25:09 -0400 (EDT) Received: from [172.16.11.125] ([134.76.241.253]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LrvBu-1eFifv3rkE-013hj7; Thu, 26 Apr 2018 17:25:05 +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: <79A11608-89FF-4353-822A-8A31D6FAC891@gmail.com> Date: Thu, 26 Apr 2018 17:25:04 +0200 Cc: Kevin Darbyshire-Bryant , "cake@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: <75E7AB38-F33C-4F20-875B-9AF3FB898C0F@gmx.de> References: <87vacf3th7.fsf@toke.dk> <46C6A124-61F3-4503-B310-C55D46597EED@gmail.com> <51A5A6AB-4B1C-4795-8136-9EB63E59598B@gmx.de> <79A11608-89FF-4353-822A-8A31D6FAC891@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.6.18) X-Provags-ID: V03:K1:9EC6+z3eiMOz9q8ky+wAnvf6MjV3B4+KefcfoviUsz6NyGjVUuS L+Ve7QFZaqtIhQ1JHXIPWNlR0xZrM6ZLsOci+d92QAi7C3e8CJ5ewSsJOHUvj8vL5/DdpXQ lHpzFGRtEn+7MawrllRvyHAN2KusUzSqNHbMYlt7kfhFzyIzQtwzRQf0yFMeHUSXFaQbSp7 yiZOqQ8cTmdXa+k/U0b4w== X-UI-Out-Filterresults: notjunk:1;V01:K0:UMwtnvM7c9s=:mFMcpQsHS6O9bDLOvD0VHI p/XNkccu60N3uR08gF1ZresZz3sRVFbq5D3tzpRtTwzqb1rfzACnCYlSRwH9D1oZs+f3hY8EH Vy0zabRbyiAlIGSqkSGvrXnja29ePSJvmYvQfI8aWYRABpMUo7YBRRI9JSOn05oUNoxMWzUsT DvGBT/ZqyOtMfdrq+OfQnP3DkzTxBVZrAbADY+M0cxoyyiX2sdFXfevaMpmsk+d/mHkm/lcU2 uTz/7W1EE+zttWrqQ7Jf26qsLo1SRbN04t6RFXHoyrANXiCAqeOAwx5/nWwjHH4zTJTjm1mhg unvt87MA0jcJcxP2Lurhsq+dXbgvAeCep7aXZPdVLlEVQ5jlpysxw2TZGdtUryVjGSlihwM2H FyTZaBGtpHwi7IO5f5t4dUr55rQtBkca6yAlWdQ9r01w+/dgONf1iW6RlL80V8MfpfWFHBVbQ 1VPuxDaiQVWcsUjHYer9AjVMVV7yh1qFD0hNphATQhOHToGIvaX0cuYIyrxTAhaXQp3C5AQNO SMgUwfHek48u4aywSm5ueatAcdooXt8/QB+lwqJjwKlhGRyPVyEcGEVzzEZjHuJ4PzbA++iLW 4ueMoTqQ545HUsqpkr7UpPKBmT/WBZUJovuU0oH8PGLtfs97XiBy6tHttiFBLjd4Ip4N6I7Xt qyHmD+fEiGtM1Yexz1zlEQq6093/49D4jeflhQiyWLdJ1OS8lr0gJtLLgpkl6DtuQ8jWJVlnY NLh/ueJ14/Z8NAC0q7Xgq9IAMj86Ul+e6vhRYoZS3d0ycxHyGGj5lubcbC/7ber9gv3JLkGTJ pSAyTjB Subject: Re: [Cake] CAKE upstreaming - testers wanted, ACK filtering rescuers needed 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, 26 Apr 2018 15:25:10 -0000 > On Apr 26, 2018, at 16:42, Jonathan Morton = wrote: >=20 >> I really liked you initial idea to make the threshold when to segment = a superpacket based on the duration that packet would hogg the = wire/shaper, as that gives an intuitive feel for the worst case = inter-flow latency induced. Especially this would allow on many links = intermediate sized superpackets to survive fine while turning 64K = "oil-tankers" into a fleet of speedboats ;). This temporal threshold = would also automatically solve the higher bandwdth cases elegantly. What = was the reason to rip that out again? >=20 > It probably had something to do with needing to scale that threshold = with the number of active flows, which isn't necessarily known at = enqueue time with sufficient accuracy to be relevant at dequeue, in = order to be able to guarantee a given peak inter-flow induced latency. = Unconditional segmentation made the question easy and didn't seem to = have very much effect on the CPU (at the link rates we were targeting). >=20 > It might still be reasonable to assume the number of active flows = won't change *much* between enqueue and dequeue. So then we could set = the threshold at, say, half the Codel target divided by the number of = active flows plus one. I am too simple minded for that, I find it more intuitive = (albeit less clever) to simply allow the user to give a limit for = acceptable superpacket serialization delay independent of the number of = bulk flows. That effectively is a configurable bandwidth threshold, once = this works reasonably well, optional cleverness might be nice to add ;) Best Regards Sebastian >=20 > - Jonathan Morton >=20