RE: Router with bandwidth management

["Mark Tinka" <mtinka at africaonline.co.ug>]

Brian, you can do full queueing, prioritisation and compression on Cisco
routers. The only restriction and limitation I would have with this is it's
not the most effective way to manage bandwidth and traffic, and is typically
recommended for use on [WAN] interfaces that support less than 2Mbps, to
solve TEMPORARY congestion problems.

The best thing to do would be to simply upgrade your bandwidth to
accommodate your growth, but just to give you some ways Cisco can shape
traffic:

The 4 main culprits are:

1. FIFO - First In First Out
2. WFQ - Weighted Fair Queueing
3. Priority Queueing
4. Custom Queueing

1. FIFO - is the most basic and straight forward. Packets are sorted and
processed based on the time they came in. The first packet that came in will
be the first to leave.

2. WFQ - allows more interactive traffic such as Telnet and SSH to have
higher priority over larger traffic such as FTP. Low volume traffic is given
higher priority. Traffic is sorted into high and low volume conversations.
Traffic in one session is kept within a single session/conversation and the
records handled FIFO-style within a particular conversation. The much needed
bandwidth is given to the more interactive, low volume traffic, and the high
volume sessions equally share what is left over. On Cisco, WFQ is on by
default for WAN interfaces that support it.

3. Priority Queueing - this gives absolute control over throughput, as well
as granular control that reduces delay for high priority traffic. Cisco's
implementation of this strategy uses 4 queues; high, medium, normal and low.
High priority traffic gets the benefit of all resources available on an
output interface until its queue is empty. The medium queue is then tackled,
and so on and so forth. Meanwhile, low priority traffic in the normal and
low queues has no choice but to wait for the higher queues to complete their
processes; but during this waiting period, traffic can age and even get
purged from memory if the queue overflows. If an overflow occurs, all new
packets meant for that queue are dropped until some space becomes available
in the queue.

4. Custom Queueing - this allows the sharing of all available bandwidth
evenly or unevenly across all traffic types. A percentage of the bandwidth
is allocated to each of the traffic types. The difference between it and
priority queueing is that its queues are processed in a round-robin
sequence, or multiplexed. So, high priority traffic won't have to be
serviced first as no traffic is designated with a higher priority over the
rest of the traffic.

But like I said, any of these methods should be used for temporary or
emergency situations. It's not considered an end-solution to bandwidth
problems. One should either upgrade, or employ a bandwidth manager +
queueing.

Regards,

Mark Tinka - CCNA
Network Engineer
Africa Online Uganda
5th Floor, Commercial Plaza
7 Kampala Rd,
Tel:   +256-41-258143
Fax:   +256-41-258144
E-mail: mtinka at africaonline.co.ug
Web:     www.africaonline.co.ug
 

-----Original Message-----
From: Brian Candler [mailto:B.Candler at pobox.com] 
Sent: Saturday, May 17, 2003 6:12 PM
To: Mark Tinka
Cc: 'Robert'; afnog at afnog.org
Subject: Re: Router with bandwidth management


On Sat, May 17, 2003 at 01:44:35PM +0300, Mark Tinka wrote:
>    As you can see above, the access list that matches your wireless
>    client's IP address is placed onto the Ethernet interface that is
>    connected to your wireless segment. In the rate-limit statement on the
>    Ethernet interface, 32000 is the bits per second allowed, 8000 is the
>    normal burst bytes and 16000 is the maximum burst bytes. As the last
>    few lines say, if the user's IP address conforms to this setting,
>    transmit his packets through. If the assigned capacity is exceeded,
>    begin to apply congestion control - basically, drop packets exceeding
>    allocated capacity.

That's the problem with Cisco's solution: it doesn't shape your traffic, it
just polices it, which means throwing away packets which exceed the
bandwidth limit. This does not give a graceful control, but relies on TCP's
backoff algorithm sensing the packet loss to ultimately reduce the
throughput, but it will never settle properly at the level you want.

For true traffic shaping, the incoming data would be stuffed straight into a
queue, and the output interface would pull packets out of this queue at your
predetermined rate (say 64kbps):

               Any  +--------------+ 64kbps
Incoming ---------> |    Queue     | ---------> Out
                    +--------------+

This is how the FreeBSD ipfw dummynet shaper works (see 'man 4 ipfw' and
scan down to 'TRAFFIC SHAPER CONFIGURATION')

This approach gives no packet loss, unless of course the queue fills up. But
each TCP session will only have at most one window's worth of data "in
transit" (typically 32K bytes) waiting for an acknowledgement.

The only way I know to do this with a Cisco is to use an ATM interface,
where you can specify the output PCR/SCR as the speed you want packets to
exit.

Regards,

Brian.




-----
This is the afnog mailing list, managed by Majordomo 1.94.5

To send a message to this list, e-mail afnog at afnog.org
To send a request to majordomo, e-mail majordomo at afnog.org and put
your request in the body of the message (i.e use "help" for help)

This list is maintained by owner-afnog at afnog.org