[j-nsp] FW: strict-high priority queue

[Harry Reynolds]

Alright, so out from the woodwork I crawl.

I did a little research and tend to think that the IE book is in need of
an update on this regard, and I have made due note.

Below is a jni thread (with names/addresses removed) that may shed light
on your issue, but I'm not sure because you indicate SH drops occur when
you alter transmit-weight. The thread summary is that the rate assigned
to a strict-high does not affect the SH queue, but *is* factored into
the calculations for the total WRR% available to other queues. This
means that changing the rate assigned to a strict-high can have an
impact on drop performance for the other queues, and in this regard the
IE book is misleading. At the same time, the thread I've pasted
indicates that one should assign the expected rate to the SH queue,
which is at odds with the tech pub example you cite. I will ping the
developers to see if they can set the record straight. You may want to
post additional details such as SW/HW version, as your description of
loss in the SH class does not match any expected behaviors I am aware
of.


Regards

Harry


[scrubbed thread]

My experience was, that transmit rate for SHP queue has influence on
behavior of ... rest of queues.

To be more detail:

- SHP queue has effectively no limits and can consume all bandwidth of
interface, but:

- if you have other queue marked as high prority (not strict), as long
as this queues are positive (in bandwidth) scheduler consider transmit
rate of SHP  and all HP when they decide from which queue packet should
be taken. When HP and SHP queues goes to deficit, then SHP is still
served by scheduler, as they will be in positive. 

- The other site effect is when you use transmit rate percentage. If you
not specify rate for SHP, then trans mit rate of remaining queues will
be aligned to 100%, then effective guaranteed rate will be too high,
because SHP traffic volume is not taken to account.

So, my advice:

- Specify transmit rate for SHP queues at level of expected traffic
volume,
- Use policer to avoid 100% of bandwidth eated by SHP traffic (if
applicable).
- in addition for SHP use HP queues for NetControll traffic.


X x x x x x
Professional Services Consultant

Juniper Networks

-----Original Message-----
From: xxxxxxxx
Sent: 03 May 2006 20:18
To: xxxxxx
Subject: Re: FW: [q] transmit rate for the strict high queue

> Could you please comment, what the semantics is for the transmit rate 
> assigned to the strict high queue (M/T)?
> In other words, what happens if I change the rate on the strict high 
> queue?

My understanding is that when using a strict high queue we essentially
add 100% to whatever transmit-rate is specified.  This makes the rate
meaningless (and you might as well not include one) since it will never
be below 100% and as such will never be negative.  

[/thread]
 

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net 
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Eric Van Tol
> Sent: Tuesday, June 13, 2006 3:20 PM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] FW: strict-high priority queue
> 
> Sorry for the duplicate post, but I haven't gotten any 
> feedback on the questions presented below.  I was hoping this 
> would be something that could be answered here, since some of 
> the authors of the Sybex books are members of the list.  
> 
> Thanks,
> evt
> 
> Subject: [j-nsp] strict-high priority queue
> 
> Hi all,
> I've been doing some testing with QoS configs and according 
> to the following page:
> 
> http://www.juniper.net/techpubs/software/junos/junos76/swconfi
> g76-cos/ht
> ml/cos-scheduler-maps9.html
> 
> if a queue is configured with a strict-high priority setting, 
> the transmit-rate has no effect because the strict-high is 
> given the full interface bandwidth.  However, from what I've 
> seen, the if the 'transmit-rate' is configured for 
> strict-high, it does have at least some effect.  For 
> instance, when configuring any rate greater than about 35%, 
> the strict-high queue starts to drop packets.  
> 
> In addition, it states that queues configured with strict-high
> *shouldn't* be configured with a transmit-rate.  However, on 
> page 655 of the Sybex JNCIE book, the expedited-forwarding 
> queue is strict-high with a transmit-rate.
> 
> Two questions:
> 
> 1.  Why does strict-high drop packets when configured with 
> too high of a transmit-rate?
> 2.  Which method is correct?  The JNCIE example or the JUNOS docs?
> 
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net 
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>