rate limits

maybe - you can use QoS to do some of the same things.

rate limiting in switches tends to be done in the hardware and may be very simple - suchas "limit broadcasts to x / sec".

my experience is they just hard block once you get to the limit until the next measurement period.

i think it best to use these as "better than melting the network" type emergency protection rather than something to control BAU traffic.

usually QoS based.

RED and friends work on packets in an outbound Q, so sort of only work once you have congestion. Although if the port is GigE or faster, you can have a lot of Q'ed packets without much delay.

the key thing is to know what you need to work with. some high end L2 switches can look at some L3 packet contents, but often dont give much flexibility in using it.

clever QoS seems to be tied to L3 functions (maybe because all the manufacturers involved seem to make both and want to differentiate the L3 stuff that costs more).

pick a vendor and pick out a mid range model box and its features for this. Then compare with others.

cisco is a good place to start simply becuase so much of their docs are online and freely accessible.

Hello

What is BAU?

I somewhere read that basically *any* available link's capacity can be filled and overfilled in a finite period of time. Something like that :-) That's why engineers came up with QoS, bandwidth management and similar concepts.

I've skimmed through a few articles in Wikipedia, and this is what conclusion I've drawn: QoS generally is a big concept (architecture, mechanism ...), comprised of a few minor, but very important, concepts -- traffic shaping, traffic classification, congestion avoidance (?? not sure this is related to QoS), scheduling algorithms and apparently many more. These minor concepts are interconnected, mutually supplement each other, and some bits of one part are used in another.

I believe my understanding is not precisely right, if I missed something, please correct me.

Certainly I will try, but I suppose their documents are vey much Cisco products specific (of course it should be :) ), and I'm now rather interested in common, general understanding, vendor independent, if it is possible.

-- Mark

sorry - "business as usual" - in others this is for those melting network moments rather than just reducing the normal level of broadcasts.

it depends :)

1 standard design technique until recently for an MPLS backbone was throw enough bandwidth at it that packets dont queue up....

much more reliable than persuading big central routers to do QoS - and then figuring out how to test it while it is in use.

That is basically it, but it is worth remembering that "good QoS" tends to be complicated in terms of resources in the boxes (ie run a lots of queues rather than 1 per interface and work out how to put traffic in then take it out) - so building it into a chipset makes for complex logic.

1 way or another you end up paying for that.

Good luck

most of my QoS books say cisco somewhere on the cover (or ATM which was the last set of stuff i worked on).

Try the RFC index - lots of QoS stuff in there, and despite being standards some at least are well written.

pull the RFC index and do a text sreach - good keywords would be qos, dscp, diffserv, queue....