[quagga-users 12556] Re: bgp - quagga-0.99.18
scharf at isc.org
Tue Nov 8 16:36:17 GMT 2011
On 11/08/2011 05:19 AM, Ingo Flaschberger wrote:
>>>> Be careful what you do with buffers. See
>>>> http://www.bufferbloat.net/ if you don't understand how big buffers
>>>> can be bad. I have to admit, I am not yet satisfied with how we're
>>>> handling buffering, and I'd like a dynamic solution. However, in
>>>> practice, we seem to be doing OK.
>>> Sorry - but this guy has no idea about buffers.
>> Um. Which guy would that be, and why do you think so?
> as Nick Hilliard outlined the size and speed of a buffer makes the
> bufferbloat does not tell which size / speed is bad - they only say
> buffers are bad - which is not true.
> Kind regards,
> Ingo Flaschberger
> Quagga-users mailing list
> Quagga-users at lists.quagga.net
Having talked to the people in question, I think these guys do know a
bit about buffers. They are trying to make near real time things work
well across the net and are running into problems. CPE equipment is the
worst offender, but termination equipment also has serious problems.
Their other point is that buffering is additive, so every buffer in the
path contributes somewhat to the problem.
When you talk about routers that deal with large aggregates of traffic,
things change a great deal. As noted by Nick, the buffers have less
impact because of wire speeds. More importantly, with many flows going
at once, any given flow has very little buffering. Assuming you are not
at a supercomputer center or google/facebook/amazon datacenter, a 10G
circuit will be carrying hundreds/thousands of concurrent flows, so the
buffering for any single flow is minimal.
On the other hand, if we are in a situation where there are few flows,
then the buffering problems start to show themselves. Even hundreds of
milliseconds of stream buffering over a few flows can become problematic
when multiplied by many router hops.
In discussion, their key point is that the answer is not bigger buffers
but better queue management. The wider the speed difference between line
hogging flows and rapid response flows, the more critical and
challenging queue management becomes. As traffic aggregation and speed
increase, the cost of more complex queue management increases and the
benefit decreases. This means there is some point at which the simple
queue management becomes the right choice.
Finally, since quagga is a control plane system, other than supporting
multipath it has no real control over the internal operation and
buffering in the forwarding plane. This means that the entire topic is a
bit off point for this list.
More information about the Quagga-users