Priscilla summed up what I was trying to get at rather well.
I just dug up the original post, and the original poster has a 56kbps link
- not even 64kbps.
"Whenever anyone sends a large print job, does a large FTP, or is browsing
the web it makes everyone else's telnet session at the remote site VERY
SLOW".
So, assuming that the default WFQ is in use, it isn't working too well at
making sure that telnet isn't affected by other traffic.
3 - 4 people doing telnet (the number given) is unlikely to starve
anything, even at Priscilla's typing speed and 56 kbps. That's why I
suggested priority queueing. But as you say, it probably won't be much
better than WFQ. Or, I suspect, than CB-WFQ, or any other queueing
strategy.
I know fragmentation is usually used for voice, but the FRF.12 agreement
refers more to 'real-time traffic'. Telnet is real-time traffic, just not
nearly as delay-sensitive as voice or video, so I reckon fragmentation
could help quite a bit given the information we have on the network.
Could the OP please let us know what they try and what the outcome is?
JMcL
----- Forwarded by Jenny Mcleod/NSO/CSDA on 05/11/2001 10:57 am -----
"VoIP
Guy"
cc:
Sent by: Subject: Re: Prioritizing
Protocols????
nobody@groups
[7:24959]
tudy.com
03/11/2001
09:53
am
Please
respond
to
"VoIP
Guy"
Just time-sensitive applications like voice, video, etc. It may help with
the telnet traffic though.
""Priscilla Oppenheimer"" wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> 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=25241&t=24959
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
