[149113] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: 10GE TOR port buffers (was Re: 10G switch recommendaton)

daemon@ATHENA.MIT.EDU (Masataka Ohta)
Sat Jan 28 07:54:53 2012

Date: Sat, 28 Jan 2012 21:53:45 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
To: nanog@nanog.org
In-Reply-To: <20120128123821.GA7545@pob.ytti.fi>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

Saku Ytti wrote:

>>> And if switch does support QoS but operator configures only BE, and
>>> operator does not limit BE queue size, operator will see buffer bloat,
>>
>> 1.5MB @ 10Gbps is only 1.2ms, which is not buffer bloat.
> 
> You can't buffer these in ingress or you risk HOLB issue, you must buffer
> these in the egress 100M and drop in ingress if egress buffer is full.

1.5MB @ 100Mbps is 120ms, which is prohibitively lengthy
even as BE.

The solution is to have less number of classes.

For QoS assurance, you only need to have two classes for
infinitely many flows with different QoS, if flows in higher
priority class receive policing against reserved bandwidths
of the flow.

						Masataka Ohta



> 
> But I fully agree, it's not buffer bloat. But having switch which does
> support very different traffic rates in ingress and egress (ingress could
> even be LACP, which further mandates larger buffers on egress) and if you
> also need to support QoS towards customer, the amount of buffer quickly
> reaches the level some of these vendors are supporting.
> When it becomes buffer bloat, is when inexperienced operator allows all of
> the buffer to be used for single class in matching ingress/egress rates.
> 



home help back first fref pref prev next nref lref last post