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 puck.nether.net
> [mailto:juniper-nsp-bouncespuck.nether.net] On Behalf
Of Eric Van Tol
> Sent: Tuesday, June 13, 2006 3:20 PM
> To: juniper-nsppuck.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/jun
os76/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-nsppuck.nether.net
> h
ttp://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net
h
ttp://puck.nether.net/mailman/listinfo/juniper-nsp
|