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

[Damon Pegg]

So you are saying that whilst two high priority queues are configured
round-robin occurs between the two so long as they are in credit, even if
one is strict-high?  This means that strict high effectively doesn't give
you anything more than if you configure a high priority queue with 100%
transmit rate, or am I missing something.  So 'strict' is just a keyword to
achieve this without breaking the calculation of the aggregate transmit
rates?  


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

If I want to run voice and video in two high priority queues, this
architecture means that I can't prioritise one (the former) over the
other..?  So this suggests that to avoid video clogging up voice traffic it
may be better to run video in a low-priority queue with high transmit-rate
and police at the edge to make sure it will always be in credit?


Thanks,

Damon.

-----Original Message-----
From: Josef Buchsteiner [mailto:josefb at juniper.net]
Sent: 04 February 2004 10:10
To: Damon Pegg
Cc: 'juniper-nsp at puck.nether.net'
Subject: Re: [j-nsp] VoIP Queuing Buffer settings & QOS Mechanics




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
strict-high
DP> queue doesn't respect the transmission-rate percent I want to use this
to
DP> effectively put an absolute (hopefully never used) cap on voice traffic
as
DP> well as guaranteeing delay/jitter per device.

    If you want to limit the VoIP high priority traffic then just
    don't use strict-high and set the priority high and rate-limit
    the transmit b/w with the exact statement.

    Strict-high has not a higher priority then just high priority.
    Strict-high just means that the credit you have will never go
    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.

    temporal setting is the buffer_delay you want to configure. This
    means you need to know what delay your Voice Gear can handle and
    set the delay accordingly.


DP> Also, Juniper recommends not using strict-high and high queues on the
same
DP> interface unless network control traffic is >5%.

    I'm not sure in which context this was communicated. But if you
    have e.g. Q2 as strict-high and Q3 is used for network control
    Q2 is able to starve out Q3. To avoid this is that you set Q3 to
    high-priority as well. The scheduler will takes first the Q with
    high and positive credit. if there are two queues with positive
    credit and high priority the scheduler will alternate between
    those two queues. This way Q3 gets served as well. The only point
    you need to watch is that Q3 configured with 5% and if sending
    6% of transmit b/w will be in negative mode for the 1% and there
    not been able to send it since the high positive credit queue
    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
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