From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id D3C4021F891 for ; Thu, 29 Oct 2015 04:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1446116552; bh=3Dog57a6iaGKAgLMsMVGxqyvtO9Kl48piftvu3bKScY=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=a6oo39/NmddSbj9OvO/Hj+Da+okMdi1MlzUcSF7p7vX15NWVN+c8ho4PHP/V9He0P oqvJ+efhdFqKRjRWFEF+7yLk0TFjHwdgS/PtJ6t8Chswl3Fc9N/KmdmNFdElbTE+Al +IADsFWLFEzRtSNtZ2hrUjvMFfQzpKZMkxXOkXM8= Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 45B5349DE8; Thu, 29 Oct 2015 12:02:31 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Sebastian Moeller References: <87twpaf0tq.fsf@toke.dk> <4B2F9D53-393D-44EC-8DC2-A59DFE0E6CBD@gmx.de> <87pozyf0cu.fsf@toke.dk> Date: Thu, 29 Oct 2015 12:02:31 +0100 In-Reply-To: (Sebastian Moeller's message of "Thu, 29 Oct 2015 11:48:01 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87h9laey48.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] memory 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: Thu, 29 Oct 2015 11:02:57 -0000 Sebastian Moeller writes: > Yes, while trying to be funny I glossed over that part a bit (the > loooong RTTs part was aiming at that), sorry. But really I am wonder > what it is that makes my position that cake should expose and honor a > packet limit for its queueing so controversial; The suggestion in itself is not necessarily controversial. However, the road to bloated interfaces is covered in good intentions. Each addition may be worthwhile in itself, but the sum of them becomes a horrible mess to configure (I'm being a bit hyperbolic here, but I'm sure you get my gist). So I'd rather say that for each possible configuration variable, we should figure out if there is a way to avoid exposing it, and only exposing it if we can't find a way to do that. Rather than going with the "easy" solution of just making it configurable and leaving the user to figure it out. -Toke