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 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 439EA21F247 for ; Tue, 3 Nov 2015 04:41:54 -0800 (PST) Received: from u-089-d061.biologie.uni-tuebingen.de ([134.2.89.61]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M1VlJ-1aiO4j0i4X-00tVZK; Tue, 03 Nov 2015 13:41:48 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <87ziyvnvlt.fsf@toke.dk> Date: Tue, 3 Nov 2015 13:41:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9BEC6A98-7DF6-4DB6-9E9F-2AD3EB39B993@gmx.de> References: <87pozspckj.fsf@toke.dk> <6A2609D9-7747-487B-9484-ECC69C50DE96@gmx.de> <87ziyvnvlt.fsf@toke.dk> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:BgaqPIKB2xOZqlV2kb03FtgWVnlqlelkqs1PoAVFOVfXTXVkPRs G/QJVakLq3xTcV8xm+BRL+j+TLcIgjF/tdmVsb+WPDjqg6ZlS7RfHVv0CysHsljuG6qofLM 4hPLuA4cOH7BNAiVLqE+98NpvJ8lGu4JYNRsfNyd4peZX3PxUMtHGjTaIOX/dYsrnJ7Bgg1 EW+7d9PE6Pb0bApLeFiBA== X-UI-Out-Filterresults: notjunk:1;V01:K0:rKsEJVuU0UE=:LHS/Ox6T98fnmbxD+vTvI/ R2A4WAiagXiYEetdLJI+F5jM6drcAf7+tS6U39RSg5soEJgkSp3Kl2nA2yKKDFCmCKhnIimHO ez7snEZ00Ej4MO8k04t191IVuXN8G4epOXsLC3d3WOQ0Nia5qQlYAEAKixsXtUlBSROcM1kig ZIUji4lZaEuC0sQPlRWm4r+sVGV5VoX3ILaGG06kv0BdYc/B7r50x3mmSSKWxWzjJ7ezr9V7P y3PDYqgqi2nQhKPhnXV8He81w+/KgWr3iD/7yYTjK77B4GDW+e5k3r8UAGp1gUhX8LQpevi+Y coSYjT4Mqmed+pVE48qvqbOA5boMpNQEdVfuuS4uxTdaf4WCkXkv9Rxk0VvzJnm6bDkNy4Soo tHgAX4CGcYnH5+H9VilIaplfKuAvwl2NQ8TgOCHfyWCYXbNthuK1+K0dEv58OGri0voNWm7fr XITiNw8zyVuFJ2+CN4wKuq7znfTpOdNpQdIZKdWIpmECJaROHMOHo0Pb6URaKVDDqK3hxLbxU j8T/dMqPQGC+cFNjsoLpMQVUG+UhumlcFbrY7aUoPvM74ujyiDcISSPgo0Ww4CzGxF0KVAmSx 9S8Ugak0ILxK6cYEDAmJ7CcXpOkdrXjoisEJgoM7vSfPB4nxrSs8ONVw+YsstaNHQCs4U5Xj1 sOkrLsxSquMqCYn9HPfjuKwBJLqb3BHH9XZJJoV5Hs/lm1S8mjmtTTRBme1IODGpVTn/iN+kt cDt/QqbRH76GwNYFwLk8uv9/gi7fVfL+9XAdGBP01RthkkIeBvi6QIUm9c3Em/o82fE1aqvfF sVv2iy3 Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Long-RTT broken again X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 12:42:18 -0000 Hi Toke, On Nov 3, 2015, at 12:57 , Toke H=F8iland-J=F8rgensen = wrote: > Sebastian Moeller writes: >=20 >> Well, I believe one of the next steps needs to be to expose limit to >> user-space, >=20 > No, just throwing the problem to user space is not a solution: it's a > cop-out. We need to fix the issues so things actually work, and then > *maybe* expose the value to userspace if there is a real need for it. > Not just go "meh, let userspace sort it out"; that is horrible design. I guess all we can do is to agree to disagree, the amount of = memory a user is willing to dedicate to a specific functionality is a = policy question in my book. It is not a cop out, as the amount of memory = the user might require for other perhaps more important functionality = can not be deduced without the users input, short of a perfect oracle.=20= >=20 >> which would have Toke allowed his measurements >=20 > No, it would not: I'm not trying to test whether we have a qdisc that, > through arcane configuration options, can be made to behave properly. Sorry, I misunderstood then, I thought the experiment was about = target at long intervals/rtts, I am genuinely sorry. > That already exists in fq_codel+HTB. What we're doing here is trying = to > build a no-knobs qdisc here that works well in all the scenarios we = can > think of. So let's make sure it does, and then talk about whether a > variable should be exposed *after* we've done proper auto-tuning. I am a biologist by training and profession, in my world there = is no perfect auto-tuning, there is just better or worse adaptation to = the current environment, the optimality of which changes with changes in = said environments that at least partly are driven by the attempt of the = environments inhabitants to improve their well being. So in other words = I believe "good-enough=94 is a reasonably achievable optimization goal, = while perfect is not; and one implication of that is that I would = appreciate to be able to do away with automatic optimization if I feel = that it gets in the way. But I realize that this is a very personal = opinion not shared by others. Given that most of your have a much = stronger CS background, I will not be too sad if I can not convince all = of you; I would be unhappy with myself if I did not at least try, = though. It is after all not the first time this isse came up, I seem to = recall that we had this limit discussion already during the codel or = fq_codel development. >=20 >> and would have followed the example of most/all other leaf qdiscs and >> put policy into user space where it arguably belongs=85 >=20 > Packet limit is not policy, it's an implementation detail. If you = don't > have the memory to run at 100Mbps / 1 second, then *set those values > lower*. You're not going to achieve it anyway if you don't have the > buffer space. So much for no-knob=85 Now the user on such a high-bandwidth = high delay link will need to actively =93lie" to cake about the link = specific parameters to avoid giving remote parties the possibility to = easily OOM his/her router, this looks a bit like DDOS on steroids to me. = This is not improved by the fact that the increased worst-case memory = demand is a (so far un documented) side effect of setting unrelated = parameters that describe parameters a user might know a priori about = her/his link. Seriously, is this as robust as we can make it? Also we do = not even report the worst case memory consumption (or a number that = strongly correlates with it) so this is not as user-friendly and obvious = as it should be. >=20 > Same thing with the target parameter, BTW: The fact that we still > haven't got it right is not an argument for exposing it to userspace, > quite the contrary: If we, the experts, can't even get it right, why = on > earth would be expect users to? Because the fact that even we are struggling might indicate that = there is no real one-size-fits-all value for target? Now, I agree that = the issues we had are not really big conceptual ones but rather small = implementation issues, but still.. Anyway, exposing limit is the white = whale I am chasing, I am fine with target somewhere between 5% to 10% of = interval, once we figured out whether at low bandwidths target is = supposed to grow to a larger fraction or not, that is... Best Regards Sebastian >=20 > -Toke