Exactly, but from the sounds of the original poster's situation, that is not available. Your right about udp - if there is enough of it, the whole exercise with the policing is pretty pointless.. I think he should use a different voip provider or isp anyway ;)
On 11 September 2010 17:33, danger will <[email protected]> wrote: > 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]<http://mc/[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]<http://mc/[email protected]> > >* wrote: > > > From: Brian Landers > <[email protected]<http://mc/[email protected]> > > > Subject: Re: [c-nsp] QoS on ingress > To: "Heath Jones" <[email protected]<http://mc/[email protected]> > > > Cc: "cisco-nsp" > <[email protected]<http://mc/[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]<http://mc/[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/
