[quagga-users 12556] Re: bgp - quagga-0.99.18

Jerry Scharf 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 
> difference.
> 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
> http://lists.quagga.net/mailman/listinfo/quagga-users

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 mailing list