Thanks for the great explanation. In my test basically i've created an artificial congestion using UDP because the effect of the congestion was mostly felt with UDP so as you confirmed this method is not effective for UDP based congestions but if we were to classify and mark and leverage the queuing provided by the mpls provider, UDP based congestions wouldn't be a problem and voip would be protected, even if the bandwidth for several sites connected to the mpls cloud is different right ?
Cheers --- On Sat, 9/11/10, Heath Jones <[email protected]> wrote: From: Heath Jones <[email protected]> Subject: Re: [c-nsp] QoS on ingress To: "danger will" <[email protected]> Cc: "Brian Landers" <[email protected]>, "cisco-nsp" <[email protected]> Date: Saturday, September 11, 2010, 4:52 PM The priority traffic will never be prioritised on the carrier egress, with or without this method. What this is trying to achieve is reducing the amount of inbound tcp traffic from the congested link. Your logic is right so far, but follow it forward in time a bit (thats what people arent doing). People are getting stuck at step 1. 1) Apply a policy for egress on the lan side, to give the voip priority over tcp traffic (reduce tcp throughput). Like you said, this wont have any effect - YET. 2) Clients on the LAN will not see the tcp traffic immediately, clients will therefore not be sending acknowledgements back to the remote end of the tcp connection. 3) The sending side will slow down the rate of transmission because it is not seeing acknowledgements coming back in as fast as it is sending segments out. This is commonly referred to as 'backing off'. The reason this works, is tcp has been designed with congested links in mind. udp and other protocols that have not, will not be affected positively (there will be no gain) from applying a policy - it is only for tcp traffic. Some links to get the idea across better: http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm http://www.ietf.org/rfc/rfc2581.txt H On 11 September 2010 14:29, danger will <[email protected]> wrote: I totally agree with Keegan queuing has to be done where the congestion actually occurs. Even if you would queue on the lan interface on output , because you can't queue on the wan interface on input that doesn't have much effect because the congestion has already occured a few hops away from you. I did some tests like this and the priority traffic didn't seem to get prioritized at least this is the conclusion i came up with. The links were mpls links and i was trying to prioritize voip traffic from another site. Do you guys have positive experiences with this method ? --- On Sat, 9/11/10, Brian Landers <[email protected]> wrote: From: Brian Landers <[email protected]> Subject: Re: [c-nsp] QoS on ingress To: "Heath Jones" <[email protected]> Cc: "cisco-nsp" <[email protected]> Date: Saturday, September 11, 2010, 5:25 AM There was actually a very interesting session at Cisco Live 2010 on inbound QoS for branch offices, using an outbound shaper on the inside interface of the router (e.g. on the gigE interface going to your switches). I don't recall the specifics, but the presenter had quite a bit of concrete data around the effects on latency, jitter, and p.loss. B* -- Brian C Landers http://www.packetslave.com/ CCIE #23115 (R&S + Security) _______________________________________________ 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/
