[c-nsp] QoS on ingress
Heath Jones
hj1980 at gmail.com
Sat Sep 11 09:52:06 EDT 2010
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<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/
>
>
>
More information about the cisco-nsp
mailing list