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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=25106&t=24959 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
