[c-nsp] QoS on ingress

[danger will]

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> 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> wrote:



From: Brian Landers <brian at bluecoat93.org>
Subject: Re: [c-nsp] QoS on ingress

To: "Heath Jones" <hj1980 at gmail.com>
Cc: "cisco-nsp" <cisco-nsp at 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
https://puck.nether.net/mailman/listinfo/cisco-nsp

archive at http://puck.nether.net/pipermail/cisco-nsp/