rate limits|
|
|
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||||||||
|
Posted by Mark on April 7, 2009, 8:45 pm
Please log in for more thread options
many L2 (and likely L3+) switches have such a feature as rate limiting. It seems such feature is applied per port basis, as well as per connection (session), if we consider L3-L4 switches. But now I'm more interested in layer2 and in this connection I have two questions to ask: (1) Is a "rate limiting" an attribute of QoS mechanism? (2) what methods/algorithms are used to limit rates of packets per port? I've read aboit random-early-drop, and weighted random-early-drop; as I know there is also a set of other algorithms. But I believe those are mainly to solve congestion problem? Or rate limit is also one of ways to fight with congestion? I would appreciate if anyone could point me at right direction :) Thanks. -- Mark | ||||||||||||||||
|
Posted by Stephen on April 8, 2009, 4:52 pm
Please log in for more thread options 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. >(2) what methods/algorithms are used to limit rates of packets per port?
usually QoS based. >I've read aboit random-early-drop, and weighted random-early-drop; as I know
>there is also a set of other algorithms. But I believe those are mainly to >solve congestion problem? 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). >congestion?
> >I would appreciate if anyone could point me at right direction :) Thanks. 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. -- Regards stephen_hope@xyzworld.com - replace xyz with ntl | ||||||||||||||||
|
Posted by Mark on April 8, 2009, 11:05 pm
Please log in for more thread options Hello
> i think it best to use these as "better than melting the network" type
> emergency protection rather than something to control BAU traffic. What is BAU? > 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. 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. > 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). >>congestion?
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. > cisco is a good place to start simply becuase so much of their docs
> are online and freely accessible. 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 | ||||||||||||||||
|
Posted by Stephen on April 9, 2009, 3:54 pm
Please log in for more thread options On Thu, 9 Apr 2009 12:05:43 +0900, "Mark"
>Hello
> >> i think it best to use these as "better than melting the network" type
>> emergency protection rather than something to control BAU traffic. >
>What is BAU? sorry - "business as usual" - in others this is for those melting network moments rather than just reducing the normal level of broadcasts. >
>> 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. >
>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. 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. >
>> 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). >>>congestion?
>
That is basically it, but it is worth remembering that "good QoS"
>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. > 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. >I believe my understanding is not precisely right, if I missed something,
>please correct me. > >> cisco is a good place to start simply becuase so much of their docs
>> are online and freely accessible. >
>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. 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. www.ietf.org pull the RFC index and do a text sreach - good keywords would be qos, dscp, diffserv, queue.... -- Regards stephen_hope@xyzworld.com - replace xyz with ntl | ||||||||||||||||
| Similar Threads | Posted |
| rate limits | April 7, 2009, 8:45 pm |
| Limits on IGMP tuning parameters | October 26, 2004, 8:53 am |
| What's the going rate for LAN wiring? | March 5, 2008, 12:37 am |
| Low FTP transfer rate when enabling Jumbo frames. | July 14, 2006, 5:46 am |
| Ethernet requirement for Data rate:100 Mbps, Distance:2-3 km | September 12, 2005, 5:54 am |
| A GbE device not able to forward full-rate odd-byte frames | November 2, 2005, 6:47 pm |
|
Home Cabling GuideFinally, an instantly downloadable book that saves you thousands in home improvement dollars! Enjoy living in 21st century technology-advanced home while increasing its selling value and competitive advantage on the real estate market. Whether your cabling is for home office or high-tech leisure, you can wire your home yourself or learn "wirish" to speak with your cabling contractors in their language! Learn More |
>
>many L2 (and likely L3+) switches have such a feature as rate limiting. It
>seems such feature is applied per port basis, as well as per connection
>(session), if we consider L3-L4 switches. But now I'm more interested in
>layer2 and in this connection I have two questions to ask:
>
>(1) Is a "rate limiting" an attribute of QoS mechanism?