On MPC2E NG or MPC3E NG cards when traffic for forwarding class A utilizes excess bandwidth permanently and second forwarding class B didn't send traffic or send traffic on a rate much lower than guaranteed rate and suddenly start sending traffic with a rate much higher than guaranteed rate, it causes temporal unexpected WRED drops of traffic for forwarding class A

The problem happens under the following conditions:

1. Interface is hosted on MPC2E NG or MPC3E NG card
2. Forwarding class A sends traffic permanently on a rate higher than guaranteed rate
3. Forwarding class B doesn't send traffic at all or send it on a very small rate
4. When huge burst of traffic for forwarding class B occurs, it impact forwarding class A and unexpected WRED drops may be observed as:

user@router> show interfaces queue xe-0/2/0.804 
Logical interface xe-0/2/0.804 (Index 366) (SNMP ifIndex 700)
Forwarding classes: 16 supported, 7 in use
Egress queues: 8 supported, 7 in use
<snip>
Queue: 4, Forwarding classes: A
 Queued:
  <snip>
  RED-dropped packets :         1124           0 pps
  <snip>
  RED-dropped bytes  :        1124000           0 bps
  <snip>

On MPC2E NG and MPC3E NG CoS functionality by default organized on XQCHIP. Described behavior is system limitation of XQCHIP. To workaround this problem, it's recommended to adjust buffer-size, shaping-rate burst-size and delay-buffer-rate CoS parameters. Exact values of these parameters are depended on design requirements.