[afnog] Bandwidth management

[Mark Tinka]

On Friday 12 March 2010 03:38:53 pm Kondie Masiye wrote:

> It is from a service provider perspective. And my routing
>  platform is mainly Huawei.

My Huawei-fu is terrible :-). One of our companies have a 
couple in the network, but if things go my way :-)...

> What sort of "considerations" would I be looking at if I
>  wanted to go with the routing platform way?

Well, in software-based routers, e.g., the Cisco 7200-VXR 
and below, the considerations aren't as many than in higher-
end, hardware-based platforms like the Cisco ASR1000 and 
above, all Juniper routing systems excluding the J-series, 
e.t.c.

Routing vendors can easily implement a number of QoS 
features in software because, well, it's software. 
Implementing the same features in hardware is much more 
difficult and would have a number of constraints depending 
on the quality of the hardware (and sometimes, software).

For instance:

	- Bi-directional rate limiting in software-based platforms
	  is thought of naturally. However, there are a number of
	  hardware-based platforms that can only support rate
	  limiting in just one direction, e.g., ingress only,
	  especially so-called Layer 3 Ethernet switches.

	- Software-based routers provide a number of match
	  conditions, e.g., IP address, Layer 4 information, Layer
	  7 information, Layer 2 information, ToS byte header
	  information, e.t.c. Some hardware-based routers may not
	  be able to support certain match conditions because such
	  functionality would need to be burned into the ASIC
	  handling packet forwarding (and lack or presence of those
	  features in the hardware may be a technical or commercial
	  consideration for the vendor).

	- In hardware-based platforms, certain line cards may only
	  have a fraction of the QoS features supported by other,
	  more potent, models. You'd have to make sure that that
 	  cheaper line card doesn't cost you important features in
	  the future. The last thing you need is a dud stuck in a
	  rack somewhere in your network :-).

	- Software-based routers can have a high degree of
	  bandwidth management granularity, in some cases on the
	  order of 8Kbps. Some hardware-based systems may be a
	  little more coarse, e.g., operate in increments of 1Mbps
	  or more.

	- Packet marking, re-marking and classification are pretty
	  straight-forward in software-based systems. Some
	  hardware-based systems may have a number of restrictions
	  on what the hardware can support when implementing these
	  sub-features for QoS.

	- Again, in QoS, the number of available queues in a
	  software-based platform may be limited by the amount of
	  memory the router supports. However, these numbers are
	  more finite in hardware-based routers as having too many
	  translates into a more expensive line card.

	- e.t.c.

All in all, software-based routers will offer you the 
broadest range of bandwidth management features and 
modularity. However, hardware-based routers will scale this 
functionality far beyond what software-based routers will 
ever support as the amount of traffic you handle continues 
to increase.

I've happily ran a Cisco 7206-VXR/NPE-G2 with a full rate 
limiting and QoS compliment up to some 950Mbps of aggregated 
bandwidth (which is just about what the NPE-G2 can manage 
anyway) without any packet drops @ 90% CPU utilization. I 
generally wouldn't recommend such a situation, but there you 
go :-)...

For your deployment, I'd suggest taking a deep and thorough 
look at what your platform supports and ensure Huawei (or 
whichever vendor you work with in the future) can support 
all the features you need. Getting an idea of their roadmap 
in this respect would be great, too. 

If you can figure that out with them, you'll sleep better at 
night implementing bandwidth management in the same platform 
forwarding your customer's packets.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://afnog.org/pipermail/afnog/attachments/20100312/c8337745/attachment.pgp>