1. I have shaped the egress port at 50 Mbps, which happens to be a WAN interface. However, I’m getting traffic rates much less than 50 Mbps. The traffic rate is worse when I’m using smaller packet sizes. I’m measuring this rate on the remote host/traffic generator.
    Answer: The traffic egressing the WAN interface is encapsulated with either VXLAN or ESP headers. The additional headers are responsible for a lower perceived packet rate. However, if you check the CLI on the appliance, you would find that the packets are being shaped at the appropriate rate. A configuration knob is provided that can be turned on to discount these packet headers for branch to branch traffic.
    service-options {  
    qos-frame-overhead {  
        auto-adjust true;  
    }  
}  


  2. I have shaped my egress port at 50 Mbps, and I’m using SCP/iPerf to test shaping of TCP stream. The traffic output is very bursty and stalls at times. I don’t see any issues with UDP traffic though. 

    Answer: By default, WRED is configured on all the queues. This has empirically proven to give much better amortized performance for a large number of TCP sessions. However, with just one TCP stream running, WRED will drop packets from the middle of the flow. The TCP behavior is then governed by the sender and receiver’s network stack. The receiver can choose not to acknowledge packets until it receives the retransmitted packet (that was dropped earlier). This can lead to timeouts, retransmission, and further congestion on the sender's network.

    A viable solution would be to configure tail drop instead of WRED drops. This works better for a single flow.

    drop-profiles {  
    tail_drop {  
        minimum 64;  
        maximum 64;  
    }  
}  


  3. I have a profile that maps a UDP stream and a TCP stream to a forwarding class. The TCP stream adapts itself to the lack of bandwidth, but the UDP can keep on pumping data at a constant rate, much higher than the configured shaping rate. Is there a way I can avoid starvation of TCP flows? 

    Answer: Yes. If you have TCP and UDP traffic going to the same forwarding class, you can separate out the drop profile. You will need to configure separate QoS policies (based on the L4 protocol along with the other conditions). You can assign a higher drop priority to UDP so that TCP traffic is not unfairly penalized. You can tune the minimum/maximum variables of the drop profiles associated with TCP and UDP drop priorities until you get the desired effect.


  4. What configuration do you suggest for video or voice traffic?  

    Answer: Both video and voice traffic need low jitter, low latency, and low drops.

    • Jitter increases if there is congestion. We need to assign it to a higher priority forwarding class (fc_ef) and allocate the required amount of bandwidth, so that it does not compete with other traffic.
    • Jitter also increases (resulting in choppy video/voice) if packets are dropped from the middle of the flow. This should be avoided by configuring tail drop rather than the default WRED.
    • Latency increases if a packet spends more time in the queue. This should be avoided by making the tail drop queue length smaller.

      All these options can be accomplished by using the policer instead of a shaper to restrict the traffic.

  5. The show interface statistics CLI command displays a higher egress rate than configured on the shaper. Why is that? 

    Answer: Shaper comes after the module TX. Run the show class-of-services interfaces set of CLI commands or the show interface port statistics CLI command to verify the actual egress rate on the interface.


  6. I have configured multiple QoS profiles and policies, but I have not configured any shaping on the interface. I do not see EF traffic being prioritized over other traffic. Why is that?  

    Answer: The various schedulers and their queues are configured only when shaper is enabled on the interface. By default, the shaping rate is set to the queues speed. As long as the shaper is configured, the traffic will be prioritized.