[j-nsp] FW: strict-high priority queue
Eric Van Tol
eric at atlantech.net
Wed Jun 14 10:37:15 EDT 2006
Thanks, Harry. I'm on an M20 running 7.5R2.8 and found that when
modifying the strict-high queue's transmit-rate percentage above 35%,
the queue would suddenly start dropping packets. My strict-high queue
is configured for expedited-forwarding of voice traffic and even with
only a single 80k G.711 stream, the strict-high would drop packets if
configured at 40% transmit-rate. The ef-class queue is using the
default drop profile:
be-scheduler {
transmit-rate percent 50;
buffer-size percent 50;
priority low;
drop-profile-map loss-priority low protocol non-tcp drop-profile
non-tcp-low-red;
drop-profile-map loss-priority high protocol tcp drop-profile
tcp-high-red;
drop-profile-map loss-priority low protocol tcp drop-profile
tcp-low-red;
drop-profile-map loss-priority high protocol non-tcp drop-profile
non-tcp-high-red;
}
nc-scheduler {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
af-scheduler {
transmit-rate percent 10;
buffer-size percent 5;
priority high;
}
ef-scheduler {
transmit-rate percent 35;
buffer-size percent 5;
priority strict-high;
}
I've read in a C-vendor book that the serialization process is a
determining factor with real-time traffic on T1/E1 links and they don't
recommend setting a strict-high queue to more than 33%. It's unclear to
me whether this is specific to the C-vendor implementation of low
latency queuing or a general rule of thumb.
evt
-----Original Message-----
From: Harry Reynolds [mailto:harry at juniper.net]
Sent: Tuesday, June 13, 2006 6:46 PM
To: Eric Van Tol; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] FW: strict-high priority queue
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
>
More information about the juniper-nsp
mailing list