[c-nsp] QoS on ingress

[Heath Jones]

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 <myniuid at yahoo.com> 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 <hj1980 at gmail.com>* wrote:
>
>
> From: Heath Jones <hj1980 at gmail.com>
>
> Subject: Re: [c-nsp] QoS on ingress
> To: "danger will" <myniuid at yahoo.com>
> Cc: "Brian Landers" <brian at bluecoat93.org>, "cisco-nsp" <
> cisco-nsp at puck.nether.net>
> 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 <myniuid at yahoo.com<http://mc/compose?to=myniuid@yahoo.com>
> > 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 <brian at bluecoat93.org<http://mc/compose?to=brian@bluecoat93.org>
> >* wrote:
>
>
> From: Brian Landers <brian at bluecoat93.org<http://mc/compose?to=brian@bluecoat93.org>
> >
> Subject: Re: [c-nsp] QoS on ingress
> To: "Heath Jones" <hj1980 at gmail.com<http://mc/compose?to=hj1980@gmail.com>
> >
> Cc: "cisco-nsp" <cisco-nsp at puck.nether.net<http://mc/compose?to=cisco-nsp@puck.nether.net>
> >
> 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  cisco-nsp at puck.nether.net<http://mc/compose?to=cisco-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
>
>