[j-nsp] VoIP Queuing Buffer settings & QOS Mechanics
josefb at juniper.net
Wed Feb 4 06:23:46 EST 2004
Wednesday, February 4, 2004, 11:53:12 AM, you wrote:
DP> So you are saying that whilst two high priority queues are configured
DP> round-robin occurs between the two so long as they are in credit, even if
DP> one is strict-high?
DP> This means that strict high effectively doesn't give
DP> you anything more than if you configure a high priority queue with 100%
DP> transmit rate, or am I missing something.
DP> So 'strict' is just a keyword to
DP> achieve this without breaking the calculation of the aggregate transmit
implicit correct however the transmit b/w settings can not exceed
100% of the total stream b/w. The reason why this is done is to
make sure the strict-high priority traffic never gets behind a long
low priority traffic and induced jitter if it does exceed a bit its
DP> Also, what is the time-frame over which the transmit-rate is calculated and
I'm not sure what you are after here. If you configure a transmit
rate of 50% you get b/w allocated to get 50% independent of the
type of interfaces you use, so I don understand why 'time-frame'
DP> If I want to run voice and video in two high priority queues, this
DP> architecture means that I can't prioritise one (the former) over the
on M-Serie today you have the current priority levels
in the right order.
DP> So this suggests that to avoid video clogging up voice traffic it
DP> may be better to run video in a low-priority queue with high transmit-rate
DP> and police at the edge to make sure it will always be in credit?
could be an option
DP> -----Original Message-----
DP> From: Josef Buchsteiner [mailto:josefb at juniper.net]
DP> Sent: 04 February 2004 10:10
DP> To: Damon Pegg
DP> Cc: 'juniper-nsp at puck.nether.net'
DP> Subject: Re: [j-nsp] VoIP Queuing Buffer settings & QOS Mechanics
DP> Monday, February 2, 2004, 12:51:24 PM, you wrote:
DP>> Anyone have experience in temporal buffer definitions for priority
DP>> strict-high type transmission scheduler queues on M series?
DP>> I'm looking for a sensible value for my VoIP queue. Since the
DP>> queue doesn't respect the transmission-rate percent I want to use this
DP>> effectively put an absolute (hopefully never used) cap on voice traffic
DP>> well as guaranteeing delay/jitter per device.
DP> If you want to limit the VoIP high priority traffic then just
DP> don't use strict-high and set the priority high and rate-limit
DP> the transmit b/w with the exact statement.
DP> Strict-high has not a higher priority then just high priority.
DP> Strict-high just means that the credit you have will never go
DP> into negative mode hence will always have positive credit.
DP>> I see several advantages in
DP>> termporal setting for the Voice queue but dont have experience in
DP>> implementing. I'm running over a gig ethernet + network.
DP> temporal setting is the buffer_delay you want to configure. This
DP> means you need to know what delay your Voice Gear can handle and
DP> set the delay accordingly.
DP>> Also, Juniper recommends not using strict-high and high queues on the
DP>> interface unless network control traffic is >5%.
DP> I'm not sure in which context this was communicated. But if you
DP> have e.g. Q2 as strict-high and Q3 is used for network control
DP> Q2 is able to starve out Q3. To avoid this is that you set Q3 to
DP> high-priority as well. The scheduler will takes first the Q with
DP> high and positive credit. if there are two queues with positive
DP> credit and high priority the scheduler will alternate between
DP> those two queues. This way Q3 gets served as well. The only point
DP> you need to watch is that Q3 configured with 5% and if sending
DP> 6% of transmit b/w will be in negative mode for the 1% and there
DP> not been able to send it since the high positive credit queue
DP> for Q2 is the first one to get scheduled.
DP>> Why is this such a problem
DP>> when the high queue can have more rigid constraints on it than the
DP>> strict-high. Surely with good buffer-size and transmit-rate settings
DP>> can be effective without being too damaging too low priority queues...
DP>> Damon Pegg
DP>> Network Development
DP>> Easynet plc
DP>> t: 0207 900 7075
DP>> f: 0207 900 4443
DP>> m: 07931 406206
DP>> e: damon.pegg at uk.easynet.net
DP>> w: www.easynet.com
DP>> juniper-nsp mailing list juniper-nsp at puck.nether.net
More information about the juniper-nsp