From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 7E4743CB3E for ; Thu, 19 Apr 2018 05:55:41 -0400 (EDT) Received: by mail-lf0-x22c.google.com with SMTP id z130-v6so6884750lff.5 for ; Thu, 19 Apr 2018 02:55:41 -0700 (PDT) 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=rsYIDTZQP0blRtttP3/DyLNgzyn+CJPirJDVU7abHDU=; b=aBrDINXMjwb5bnGrHiaIsgrVgF9rXMdpbILu9g92yv93rUZJIHLYPcb7IkU+0gNELR WED1sjUYTUqdl90Ecb6Jzx04cSnSgbReYN/V32yUsopUek6DWdB3RkWD7L9CrOSNkbQE esUd4065MyApUk6VmOKbHZq2Y4F7MCyvBRkCKT6lVQkz158TdOGPoAJjOtuZ0gCmSX86 44ORQhDQbXhmoPdgklGdLYut8zE7XAn0LAZbDvi3Q1xLed+5ZXP5VHSocm7shs4zuvVQ W2WsLLJ+WQYnscj0c521bqb/DFog9cvYcYmjZaxL1/vFsSAAbpHp6HEfPr3RL8cCN4BQ hfJA== 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=rsYIDTZQP0blRtttP3/DyLNgzyn+CJPirJDVU7abHDU=; b=ceRwj2ZnZQ2nLaN+te6zTjvLfHsX7s2gitSZCUvyRBGHSgRRC7h2BuOF2HYMG9S24/ 6yJYMnFmwlZHPk9VYIJAHObkszEbeVynLKiz0bpvYb2Z5Nl2R7Ri8eIdBMf5ngm29YHn naP5d/WbycW3YxBoOHmD9oqn1pWor/xbCZVXmP8F8Fe8GVURrDkq/nJnzfS56qrAs9rI NEHcj95EPtAIB3hw2VBN8vn/bEQd7UEkfPHNVHp+xhuDpGeDVQbH3kn2SnOsqNH/nilo t1sRxkFeR75NjNjHYwvtO5TjN09k2H03apn8mm0gD6CPzSfg/aB9S0Rnf6aBd8UYmBui tevA== X-Gm-Message-State: ALQs6tDG8ia+y/ouL0R+P7obiIC7sQYFwvobNce1Di4AsOTQv1jkXPwL 0ue4qscrS56iWEffGupsWUg= X-Google-Smtp-Source: AIpwx49FAXMbPd3oRuJpkbywB/cC+xzu1llbSHNxopQxlUD3uchH7Oc20oNToAUYPXXQCzy4ppYbJw== X-Received: by 10.46.69.5 with SMTP id s5mr1604449lja.41.1524131740369; Thu, 19 Apr 2018 02:55:40 -0700 (PDT) Received: from [192.168.239.216] (83-245-234-255-nat-p.elisa-mobile.fi. [83.245.234.255]) by smtp.gmail.com with ESMTPSA id l8sm509125ljh.78.2018.04.19.02.55.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 02:55:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Jonathan Morton In-Reply-To: <87y3hjzgvz.fsf@toke.dk> Date: Thu, 19 Apr 2018 12:55:37 +0300 Cc: Luca Muscariello , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: 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> <87d0yv1sfz.fsf@toke.dk> <3B813EB8-92E7-402D-8BF5-DD43971155E4@gmail.com> <87y3hjzgvz.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.6.18) 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: Thu, 19 Apr 2018 09:55:41 -0000 >>> your solution significantly hurts performance in the common case >>=20 >> I'm sorry - did someone actually describe such a case? I must have >> missed it. >=20 > I started this whole thread by pointing out that this behaviour = results > in the delay of the TCP flows scaling with the number of active flows; > and that for 32 active flows (on a 10Mbps link), this results in the > latency being three times higher than for FQ-CoDel on the same link. Okay, so intra-flow latency is impaired for bulk flows sharing a = relatively low-bandwidth link. That's a metric which few people even = know how to measure for bulk flows, though it is of course important for = sparse flows. I was hoping you had a common use-case where *sparse* = flow latency was impacted, in which case we could actually discuss it = properly. But *inter-flow* latency is not impaired, is it? Nor intra-sparse-flow = latency? Nor packet loss, which people often do measure (or at least = talk about measuring) - quite the opposite? Nor goodput, which people = *definitely* measure and notice, and is influenced more strongly by = packet loss when in ingress mode? The measurement you took had a baseline latency in the region of 60ms. = That's high enough for a couple of packets per flow to be in flight = independently of the bottleneck queue. Therefore, the most severe = effects of fq_codel's configuration (and Cake's old configuration) are = less obvious, since TCP is still kept operating in a regime where its = behaviour is vaguely acceptable. Aggregate goodput remains high anyway, = due to the large number of flows involved, but I would expect the = goodput of individual flows to show odd behaviour under fq_codel. I would take this argument more seriously if a use-case that mattered = was identified. So far, I can't even see a coherent argument for making = this tweak optional (which is of course possible), let alone removing it = entirely; we only have a single synthetic benchmark which shows one = obscure metric move in the "wrong" direction, versus a real use-case = identified by an actual user in which this configuration genuinely = helps. And I've tried to explain why I believe this to be the Right Thing to do = in general, contrary to Dave's opinion. - Jonathan Morton