[j-nsp] VoIP Queuing Buffer settings & QOS Mechanics

[Josef Buchsteiner]

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?

    correct.


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.

    correct

DP>   So 'strict' is just a keyword to
DP> achieve this without breaking the calculation of the aggregate transmit
DP> rates?
DP>

   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
   allocated b/w.


DP> Also, what is the time-frame over which the transmit-rate is calculated and
DP> replenished?
DP>

   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'
   matters here



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
DP> other..?

    on M-Serie today you have the current priority levels
    in the right order.

    high +ve
    low  +ve
    high -ve
    low  -ve


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> Thanks,

DP> Damon.

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> strict-high
DP>> queue doesn't respect the transmission-rate percent I want to use this
DP> to
DP>> effectively put an absolute (hopefully never used) cap on voice traffic
DP> as
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> same
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> this
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>> _______________________________________________
DP>> juniper-nsp mailing list juniper-nsp at puck.nether.net
DP>> http://puck.nether.net/mailman/listinfo/juniper-nsp