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-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A440021F18A for ; Tue, 25 Feb 2014 06:19:21 -0800 (PST) Received: from u-089-cab204a2.am1.uni-tuebingen.de ([134.2.89.3]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LoJDJ-1WtrjT0zZh-00gIIY for ; Tue, 25 Feb 2014 15:19:18 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Tue, 25 Feb 2014 15:19:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54AF617E-908B-444A-B424-076795446363@gmx.de> References: <530C7AFA.2070101@gmail.com> <247B6C2F-1A7E-41F8-9E59-04419060E702@gmx.de> To: Maciej Soltysiak X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:36RipfHzbH5ZUMcfX7Y/2l5v5zXa4aBYrg5+9z9baldbP2LuH8y EOVbgftNjvD274Yq5kMIHq5ySudSWq4H3BkmdFKsm5gKwfvVKWUNj7OiOU8hQw66nDd1UHc S+Vr10V507x9vGkNiblDut2Hkgz1f9LG2uZqhWnH1sNXF5fu8B2Y/Vrohhl6KOdQfeysU+L kGqKm7V1QZiB6mMmUv8lQ== Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] uplink_buffer_adjustment X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 14:19:22 -0000 Hi Maciej, On Feb 25, 2014, at 15:05 , Maciej Soltysiak = wrote: > On Tue, Feb 25, 2014 at 1:08 PM, Sebastian Moeller = wrote: >> TL:DR version, netalyzr probes a buffer depth that while = existing has not much relevance on the latency behavior under load for = cerowrt. > Yes, it doesn't have much relevance for latency where fq_codel or > similar are employed. Exactly. > But where it's not (or where fq_codel is defeated by DOS style > traffic), it seems this comes back as a meaningful metric. That is what I thought as well initially,. But then (I think = Eric D explained) if the system is under a DOS attack we have more = severe problems at hand than ping latency ;) Think about it that way, if = the flood saturates our uplink, fq_codel will sooner or later reign it = in anyway, and we only see a temporary glitch in latency performance = (during the time the queue stays in tail-drop or so). If the DOS attack = is coming from the outside against our system we are hosed anyway, as a = the upstream CMTS/DSLAM?BRAS buffers will fill up over which we have no = control (as typically the ingress of a DSLAM is much greater than the = egress to a specific line so there is going to be an normally temporary = queue). I think during a DOS all hops with ingress-from-DOS > = egress-to-destination will see buffers filing up... So my current thinking is it is nice to have some buffering = against large swings in available bandwidth to smooth out the traffic a = bit. On the topic of the limit parameter I want to add, that I see the most = relevant part of limit to keep cerowrt out of out-of-memory conditions = which will cause the unit to reboot. So ideally the total amount of = buffering in the system stays low enough so the box does not go = belly-up.=20 > In the end > codel is workaround for overbuffering, which is not being removed very > hastily. I beg to differ, once the buffer management gets smart buffers = turn from liability to a boon ;) Best Regards Sebastian >=20 > Best regards, > Maciej