[c-nsp] shaping outbound

[Saku Ytti]

On (2011-12-25 14:46 -0600), Anton Kapela wrote:
 
> A rule of thumb I've kept in mind is to shape at ~80% of the overal
> CIR from your isp. Then, apply queueing to taste. A fairly useful &
 
> Same for upstream, though, you can typically get away shaping within
> 95% of the configured CIR bitrate. Say you had 5 mbits/sec upstream.

As I understand this, this is due to different platforms calculating
different things in shaper. If you know exactly what shaper is doing, and
your congestion point is constant rate, you can configure it to 100%

ES20 calculates L1 speed, ES+ and SIP400 calculate L2 speed. 

So consider you have topology as such

ES+ -10GE- metrol2 -FE- customer

There is no QoS in metrol2<>customer, but there is QoS on ES+>customer
subinterface.

Per default if you set ES+ shaper to 100Mbps, the shaper will think traffic
rate is in-contract and will forward, while actual L1 rate exceeds FE
physical rate and metrol2 is forced to drop frames out-of-contract.

In this graph I'm sending traffic in above topology and around 130s mark I
apply 'hw-module slot 2 account np 0 out 24' to the ES+ card.

http://ytti.fi/after.png

So what happens here is, before above command the metrol2 is dropping
packets, ES+ is passing through shaper. After telling the ES+ card to
calculate L1 speed, it notices that traffic is out of contract and it can
start dropping BE traffic, keeping other classes undropped.

(24B == preamble + SFD + CRC + IFG)

It gets really wonky if you have to do QoS on ethernet interface for
downstream ATM congestion point, some boxes are able to account for cell
overhead in Ethernet interface, but that is somewhat rare selection of
boxes.

Often people just tinker with shaper rate to make it less than 100% to
accomplish the same. But it's suboptimal solution, as overhead is not
constant, in ATM very much so but even in ethernet you cannot get reliable
results for all frame size spreads if your shaper is calculating wrong
speed.
Of course if you only ever run QoS in the last-mile interface, where actual
congestion occurs, things get very very easy. QoS in aggregation takes
care.

-- 
  ++ytti