From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 856C33CB39 for ; Thu, 19 Apr 2018 05:00:49 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1524128448; bh=ag2meHzc0P/RGIoK/9UkD9v1rwsJ2JAa57D/WCSZmxg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=F1uXcauYjoTFlXDXCMxmYXJxiU6zFviyDdXVXMXVCfUJ7fyWXjt1oPaei9ssqWTQw ConRlJ8MkoqVVtMI2+WF6ZhWl3c6H1Nbhet76hIrS6mhq7eZIFvfYuCknIS4AhJGfC +/Tc2o67wCJCLhYMdyBl6scTmQ1iJeknFoxr+166BgP3KMdU8Cqt/Y3yXQg8X0eHsV lpvPj9CEC+LEq753HR7rmHxhjEbBtcwyxCs/7Gg0hqWfXkdXXOG9NdSE6vOVI6M/ql 25CYH18eTgCk8+N9cMwsSwKGtfn17mTiDymwPgfOVKJgGkLxFE9HPZxTbUO3XHIcB1 r3dStjw1Fh34w== To: Jonathan Morton , Luca Muscariello Cc: Cake List In-Reply-To: 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> Date: Thu, 19 Apr 2018 11:00:48 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87d0yv1sfz.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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:00:49 -0000 Jonathan Morton writes: >> This is why I think that any fix that tries to solve this problem in >> the queueing system should be avoided. It does not solve the real >> problem (overload) and introduces latency. > > Most people, myself included, prefer systems that degrade gracefully > instead of simply failing or rejecting new loads. Systems that exhibit > the latter behaviours tend to be open to DoS attacks, which are > obviously bad. Or users obsessively retry the failed requests until > they succeed, increasing total load for the same goodput and inferior > perceived QoS. Or ignorant application developers try to work around a > perceived-unreliable system by spamming it with connections so that > *their* traffic ends up getting through somehow. > > By designing a system which exhibits engineering elegance where > practical, and graceful degradation otherwise, I try to encourage > others to do the Right Thing by providing suitable incentives in the > system's behaviour. The conventional way (of just throwing up one's > hands when load exceeds capacity) has already been tried, extensively, > and obviously doesn't work. Cake does better. Except this is not simply a question of "better and more elegant". It is a tradeoff between different concerns, and your solution significantly hurts performance in the common case to accommodate a corner case that quite fundamentally *can't* be solved properly at the queueing level, as Luca points out. -Toke