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

[Peter Rathlev]

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.

-- 
Peter