I am not sure microflow policing is what is needed here... RED or WRED is supported on GSR and CRS. It is very widely deployed.
UDP does not react well to WRED, and you get most of the benefit for TCP based flows, which would slow down on a single drop, while UDP would not react... Sometimes it would just be worse... It would retransmit. Try to split the classes in such a way that your bursty UDP traffic hits a tail drop policy. It does not have to be a separate class, but could be just a different WRED profile with the min/max thresholds being equal (or very close, which is virtually a tail drop policy). Look at QOS-Group based WRED. QOS-Group is a local property you can assign different flow types (using an MQC policy on ingress) even if they use the same DSCP/Prec markings. This would be difficult on an MPLS P node, as it only sees the MPLS labels... Arie -----Original Message----- From: cisco-nsp [mailto:[email protected]] On Behalf Of Nick Hilliard Sent: Thursday, June 6, 2013 4:10 AM To: Dhamija Amit Cc: [email protected] Subject: Re: [c-nsp] Flow based RED On 06/06/2013 09:41, Dhamija Amit wrote: > Could you please help me out if flow based RED is supported in CRS & > GSR Platform , it seems currently we don't have any mechanism to limit > the UDP burst when we have WRED (with both TCP & UDP in same queue) > and only TCP reacts when buffer is full. I think flow based RED could > be a good solution if we are mixing TCP & UDP together. microflow policing is only available on PFC3/PFC4 based platforms, as far as I'm aware. Nick _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
