[Cerowrt-devel] uplink_buffer_adjustment

[Sebastian Moeller]

Hi Maciej,


On Feb 25, 2014, at 15:05 , Maciej Soltysiak <maciej at soltysiak.com> wrote:

> On Tue, Feb 25, 2014 at 1:08 PM, Sebastian Moeller <moeller0 at gmx.de> 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. 

> 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

> 
> Best regards,
> Maciej