[c-nsp] Egress QoS on FE links with less than 100Mbps speeds

[Lobo]

Hi Peter.  The reason why the radio only works at less than 100M is 
because that's all the bandwidth it has.  This is licensed based 
wireless technology for point to point shots between buildings.  
Bandwidths can be anywhere from 18M to 400M depending on which frequency 
you use and radio brand.  For that 400M radio we use Gig interfaces so 
we would need to use the bandwidth limit command to make sure that it 
only operates at 40% vs 100%.

So for the 2950s and 3550s it looks like we may not have much wiggle 
room.  My recommendation might be to upgrade those all to 3750s.  :)

Thanks.

Jose


On 12/16/2009 2:55 PM, Peter Rathlev wrote:
> On Wed, 2009-12-16 at 08:45 -0500, Lobo wrote:
> [...]
>    
>> There are times when the link is only capable of hitting say 80Mbps
>> (we're a wireless isp) or less.
>>
>> Since we have to use a FE port for this type of connection, do the
>> switches believe that they have 100Mbps of bandwidth to play with when
>> putting packets into the appropriate queues?
>>      
> The interface will take packets from the output queue and send them as
> fast as it can, so as long as there are packets to be sent they will be
> sent at 100 mbps.
>
>    
>> I'm a bit confused as to how the switches work in this fashion.  If I
>> were using CAT5 cables or fiber this would be simple to understand as
>> the bandwidth would be fixed.  :)
>>      
> The interesting things happen in the box that converts from 100 mbps to
> something less, i.e. the wireless bridge. Why is it sometimes less than
> 100 mbps? Is it simple loss because of varying signal quality? Does the
> wireless bridge compensate for this loss by retransmitting at layer 1,
> meaning a little RTT variance and some lost bandwidth? Or does it just
> drop and let the overlying protocols handle this? (In short: how do you
> measure it? TCP throughput is not a reliable measurement.)
>
> About the switch: The WRR you configure (on a 3550) is "Weighted Round
> Robin"; it doesn't define anything relating to how much bandwidth there
> actually is, it just defines how many packets from each queue to serve
> to the interface tx ring in each turn.
>
> The important bit though is IMHO that you use the priority queueing.
> This means that queue 4 (CoS 5) will _always_ be sent first. This should
> minimise loss when traffic crosses the wireless bridge.
>
>    
>> The switches that we use are 2950, 3550, 3750 and 6524s.
>>
>> With MQC and "layer 3" QoS, I would know how to fix this by simply using
>> the "bandwidth" command on the physical interface and basing my output
>> policy-map to use "bandwidth percent" for each class.  Layer 2 QoS
>> doesn't seem to work this way though.
>>      
> On the 3750 you can use what Daniel mentioned: "srr-queue bandwidth
> limit". AFAIK this just uses a time divisioning on the interface and
> throws away unused timeslots. Bear in mind that if the wireless bridge
> has a very shallow queue this might not work very well.
>
> This command isn't available on the 2950 or 3550. And even though a few
> (10GE) ports one the 6500/7600 platform support SRR, you can't cap the
> interface as such like this.
>
>