Mailing List Archive

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@uk.easynet.net
DP> w: www.easynet.com

DP> _______________________________________________
DP> juniper-nsp mailing list juniper-nsp@puck.nether.net
DP> http://puck.nether.net/mailman/listinfo/juniper-nsp

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@juniper.net]
Sent: 04 February 2004 10:10
To: Damon Pegg
Cc: 'juniper-nsp@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@uk.easynet.net
DP> w: www.easynet.com

DP> _______________________________________________
DP> juniper-nsp mailing list juniper-nsp@puck.nether.net
DP> http://puck.nether.net/mailman/listinfo/juniper-nsp

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@juniper.net]
DP> Sent: 04 February 2004 10:10
DP> To: Damon Pegg
DP> Cc: 'juniper-nsp@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@uk.easynet.net
DP>> w: www.easynet.com

DP>> _______________________________________________
DP>> juniper-nsp mailing list juniper-nsp@puck.nether.net
DP>> http://puck.nether.net/mailman/listinfo/juniper-nsp