On Sat, Sep 11, 2010 at 9:52 AM, Heath Jones <[email protected]> wrote:
> 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'. > I agree that TCP will back off if policed however if he only has 1M to work with he might be stuck. I've filled up a 1M pipe with an iPhone... If there are enough TCP sessions the congestion will still happen. > 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]< > 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/ > > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
