[j-nsp] RED Drops with Qos
Li Zhu
lz6 at njit.edu
Tue Dec 22 09:37:46 EST 2009
Scott,
I think the packet dropping is unavoidable, no matter how you configure RED.
Most of the time, your TCP is in congestion avoidance state, it increases
its transmission window size by one every RTT (round trip time). In other
words, it will increase its transmission rate till congestion happens (that
is when RED or tail drop kicks in). After TCP detects packet drops, it will
decrease its window size by half ,and start increasing its transmission
window size by one every RTT till congestion happens again.
If you are using MS Windows TCP, Windows has a default limit on the maximum
TCP window size (I do not remember the exact number). So if you have enough
number of T1 to support the maximum TCP transmission rate limited by the
maximum window size, you will not see drops. You can also change the
maximum TCP window size to much larger number by editing the registry.
Li
On Mon, Dec 21, 2009 at 4:58 PM, Scott Berkman <scott at sberkman.net> wrote:
> Derick,
>
> FYI after making your suggested changes I am still seeing drops:
>
> show configuration chassis fpc 2 pic 2
> red-buffer-occupancy {
> weighted-averaged {
> instant-usage-weight-exponent 9;
> }
> }
>
> show interfaces queue ds-2/2/0:1:5:1
> Physical interface: ds-2/2/0:1:5:1, Enabled, Physical link is Up
> Interface index: 165, SNMP ifIndex: 79
> Description: Test-1
> Forwarding classes: 4 supported, 4 in use
> Egress queues: 4 supported, 4 in use
> Queue: 0, Forwarding classes: be
> Queued:
> Packets : 290 0 pps
> Bytes : 375596 0 bps
> Transmitted:
> Packets : 268 0 pps
> Bytes : 346908 0 bps
> Tail-dropped packets : 0 0 pps
> RED-dropped packets : 22 0 pps
> Low, non-TCP : 0 0 pps
> Low, TCP : 22 0 pps
> High, non-TCP : 0 0 pps
> High, TCP : 0 0 pps
> RED-dropped bytes : 28688 0 bps
> Low, non-TCP : 0 0 bps
> Low, TCP : 28688 0 bps
> High, non-TCP : 0 0 bps
> High, TCP : 0 0 bps
>
> Thanks,
>
> -Scott
>
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Derick Winkworth
> Sent: Monday, December 21, 2009 4:41 PM
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] RED Drops with Qos
>
> By default, in JUNOS, there is no weighted average for RED. Queue-depth is
> evaluated in an instantaneous fashion. This means, of course, that there
> is
> no allowing for transient bursts.
>
> Under the chassis/pic hierarchy you must enable weighted-average RED and
> you
> should put a weight of 9 as a start.
>
>
>
>
>
>
> ________________________________
> From: Scott Berkman <scott at sberkman.net>
> To: juniper-nsp at puck.nether.net
> Sent: Mon, December 21, 2009 3:11:40 PM
> Subject: [j-nsp] RED Drops with Qos
>
> Hi All,
>
>
>
> I'm fairly new to Juniper, and I am trying to get our QoS
> setup right on a M20 running JunOS 8.3 being used for T1 aggregation.
>
>
>
> The PIC is an IQ-enabled ChOC12 card, and the interfaces are
> channelized T1's. We seem to be classifying traffic into the 4 queues
> correctly, but no matter what I change in the settings I am still seeing
> RED
> drops on TCP/Low traffic.
>
>
>
> Please find below the base configuration sections I am starting with. I
> have tried some different percentages, and tried defining specific
> drop-policies based on some suggestions in the achieves from this list, but
> no matter what I still see the drops in the same place.
>
>
>
> Are there any good best-practice guides to QoS on JunOS? I
> see lots about how the different settings effect the flow, but nothing in
> terms of what works well for others. Also is there anything obviously
> wrong
> below?
>
>
>
> Thanks in advance for any help,
>
>
>
> -Scott
>
>
>
> classifiers {
>
> dscp DSCP-CLASS {
>
> forwarding-class ef {
>
> loss-priority low code-points 101110;
>
> }
>
> forwarding-class af {
>
> loss-priority low code-points [ 011000 011010 ];
>
> }
>
> forwarding-class be {
>
> loss-priority low code-points 000000;
>
> }
>
> forwarding-class nc {
>
> loss-priority low code-points 111000;
>
> }
>
> }
>
>
>
> forwarding-classes {
>
> queue 0 be;
>
> queue 1 ef;
>
> queue 2 af;
>
> queue 3 nc;
>
> }
>
>
>
> scheduler-maps {
>
> VOIP-MAP {
>
> forwarding-class be scheduler be-sched;
>
> forwarding-class ef scheduler ef-sched;
>
> forwarding-class af scheduler af-sched;
>
> forwarding-class nc scheduler nc-sched;
>
> }
>
> }
>
>
> schedulers {
>
> be-sched {
>
> transmit-rate percent 10;
>
> buffer-size percent 10;
>
> priority low;
>
> }
>
> ef-sched {
>
> transmit-rate percent 80;
>
> buffer-size percent 80;
>
> priority strict-high;
>
> }
>
> af-sched {
>
> transmit-rate percent 5;
>
> buffer-size percent 5;
>
> priority high;
>
> }
>
> nc-sched {
>
> transmit-rate percent 5;
>
> buffer-size percent 5;
>
> priority high;
>
> }
>
> }
>
>
>
> Example interface:
>
> ds-2/2/0:1:1:1 {
>
> scheduler-map VOIP-MAP;
>
> unit 0 {
>
> classifiers {
>
> dscp DSCP-CLASS;
>
> }
>
> }
>
> }
>
>
>
> I also tested with the following scheduler and still saw the drops:
>
> be-sched {
>
> transmit-rate percent 80;
>
> buffer-size percent 80;
>
> priority high;
>
> }
>
> ef-sched {
>
> transmit-rate percent 10;
>
> buffer-size percent 10;
>
> priority high;
>
> }
>
> af-sched {
>
> transmit-rate percent 5;
>
> buffer-size percent 5;
>
> priority high;
>
> }
>
> nc-sched {
>
> transmit-rate percent 5;
>
> buffer-size percent 5;
>
> priority high;
>
> }
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
More information about the juniper-nsp
mailing list