At 03:57 PM 11/2/01, VoIP Guy wrote: >CB-WFQ (class-based WFQ) isn't enabled by default. It is started with the >class-map (name), access-lists and policy-map (name) commands. It combines >the best practicesof WFQ, WRED and proiority/custom queuing. It is highly >customizable. You just create different policy-map's for the different >types of traffic (RED data during congestion but not voice, give RTP from >site A to site B priority, etc)
Thanks for the info. It sounds like a good choice. >If the original poster is just trying to pritorize only telnet traffic above >all alse, there is absolutly no configuraton needed, cause WFQ is default >below E1 speeds and telnet is by default already prioritized above all other >traffic conversations. > >I was thinking the poster had other types of traffic like FTP, http, SMB >traffic, etc., I think that was the case, but the default WFQ wasn't doing a good enough job. > which is why the interleaving comes into play, (especially >the FTP traffic). >I can almost guess that Telnet traffic alone wouldn't >starve any traffic out (around 23 bytes/packet or something like that) and >interleaving it wouldn't touch it at all, since it's below the 80 bytes that >interleaving would chop at on a 64k link. Telnet sends one character typed per packet by default! But it does get padded, since it starts on Ethernet usually, to 64 bytes. But what's relevant is that interleaving could chop up the other (FTP, etc.) large packets to reduce serialization delay. I've never heard of using it for something other than voice, though, have you?? >Furthermore, if the link is constantly backed up, I'd upgrade bandwidth, as >queuing is only supposed to be used when there is intermittent congestion. That's for sure! Thanks Priscilla >If I could type 90 words a minute, I'd write a book too :) > > > >""Priscilla Oppenheimer"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > At 01:35 PM 11/2/01, VoIP Guy wrote: > > >I would use CB-WFQ, over all the others because of the control you can > > >create. > > > > > >Protrity queuing will "starve" out the other protocols if one is given > > >priority over the others and it is busy. > > > > Yes, but Telnet may not be so busy that it would cause a problem. It's >true > > that priority queuing would always check for Telnet traffic first, but if > > there isn't any Telnet traffic, then it would move on. Telnet sends >traffic > > as someone types. Now, I can type 90 words a minute (though not with much > > accuracy) but a lot of people can't type that fast. ;-) > > > > Seriously, it would be a good idea to test to see if prioritizing Telnet > > would cause a problem or not. It would depend on the number of users, >their > > usage patterns, and the applications they are using. > > > > > > >Frame-relay Fragmentation (FRF.12) is an interleave and traffic shaping > > >comand, and as such will minimize seialization > > > > The original message is long gone but I think he said he had 64-Kbps >links, > > so the serialization delay to send long packets (while Telnet waits) is > > significant. > > > > >, but not prioritize. I would > > >use it, but in concert with WFQ. > > > > WFQ would be enabled by default. I don't know about CB-WFQ though?? > > > > > > >Steve Ridder > > > > > > wrote in message > > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > I accidentally deleted the original post - ah well. > > > > We have a similar problem here - which we are hoping to solve by >moving > > >the > > > > unix box to where the users are :-) > > > > However I assume you have users at the central site who are using it >as > > > > well. > > > > > > > > I suspect that your overall proportion of telnet traffic is probably > > >pretty > > > > low, so you could probably implement priority queueing to give your > > telnet > > > > traffic absolute priority with very little risk of locking out other > > > > traffic. > > > > However, it could just be that telnet packets are getting queued >behind > > > > large ftp packets and getting hit by a large latency - priority >queueing > > > > won't cause a telnet packet to preempt a large packet already on the >wire > > > > (which is probably just as well). > > > > If priority queueing doesn't fix the problem, perhaps you should look >at > > > > some of the QoS techniques used to minimise latency for voice? For > > > > example, frame relay fragmentation? > > > > > > > > JMcL (attempting to put into practice - even if vicariously - a voice > > > > course done recently ;-) > > > > > > > > > > > > ----- Forwarded by Jenny Mcleod/NSO/CSDA on 02/11/2001 02:25 pm ----- > > > > > > > > > > > > "Michael > > > > Williams" To: > > > > [EMAIL PROTECTED] > > > > Subject: Re: Prioritizing > > > > Protocols???? > > > > Sent by: > > > > [7:24959] > > > > > > > > nobody@groups > > > > > > > > tudy.com > > > > > > > > > > > > > > > > 02/11/2001 > > > > 06:56 > > > > am > > > > > > > > Please > > > > respond > > > > to > > > > > > > > "Michael > > > > > > > > Williams" > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree with the other posters here. Let us know what those 1601 > > support. > > > > Priority queuing with work, but Weighted-Fair (which should, as the >other > > > > poster said, handle this already) is the best choice for this. > > > > Weighted-Fair is setup in a way the high bandwidth traffic doesn't >choke > > > > small bandwidth applications (like Telnet). Otherwise Priority or >Custom > > > > queueing are your only other options..... (AFAIK) > > > > > > > > Mike W. > > ________________________ > > > > Priscilla Oppenheimer > > http://www.priscilla.com ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=25122&t=24959 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
