From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 891023B2A4 for ; Fri, 24 Nov 2017 15:41:02 -0500 (EST) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id A8373220ED; Fri, 24 Nov 2017 20:41:00 +0000 (UTC) From: Dave Taht To: Pete Heist Cc: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= , Cake List References: <71FB183D-F848-4513-A6F6-D03FD0F10769@gmail.com> <52C2B216-220C-4C17-882C-9994867E86BB@gmail.com> <87tvxlvsex.fsf@nemesis.taht.net> <87609zapmt.fsf@toke.dk> <0D339F2F-F2CB-4800-84B9-E7321AE4D15E@gmail.com> Date: Fri, 24 Nov 2017 12:40:58 -0800 In-Reply-To: (Pete Heist's message of "Fri, 24 Nov 2017 20:41:36 +0100") Message-ID: <87fu93wgth.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] lan keyword affects host fairness 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: Fri, 24 Nov 2017 20:41:02 -0000 Pete Heist writes: > On Nov 24, 2017, at 2:49 PM, Pete Heist wrote: >=20=20=20=20=20 >=20=20=20=20=20 > Removing the bandwidth keywords altogether and going back to fq_codel= =E2=80=99s > specification of target and interval would be my personal preference = (unless > we can figure out how to make the keywords work well with one another= in all > cases). > > To add to my comments, this probably came across as too harsh or disconti= nuous > an idea at this stage when we=E2=80=99re in the process of shoring things= up- that > wasn=E2=80=99t my intent! Well, I expected bumps on trying to get stuff to mainline. This is just text and documentation.=20 The major speedbump would be breaking the xstats API, the testing and flag day it would entail, etc. I had spare time sufficient to clean things up, not make major changes like that. > > There is the other side that these keywords save people from having to kn= ow > more. Which is better, explaining target and interval to everyone or havi= ng them > use these? Something that even an ISP could configure. > I imagine that was the logic that went into it. Also, if it=E2=80=99s not= a > good idea to be changing the configuration interface at this point (and i= t may > not be), then there are alternatives, and the man page addition will defi= nitely > help people. Maybe I=E2=80=99ll make some runs across a range of rtts to = understand this > better=E2=80=A6