Re: [c-nsp] QoS on ingress
On Sat, Sep 11, 2010 at 10:27 PM, Keegan Holley keegan.hol...@sungard.com wrote: 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. Agree. Without explicit queue assignment/priority on the PE egress interface, anything you try to do on the CE is going to be best effort in terms of effectiveness. Shaping all non-voice inbound traffic to 90% or so of your CIR to try to protect the voice traffic is probably about the best you can do. A significant amount of non-voice UDP traffic is still going to kill you, though. B* -- Brian C Landers http://www.packetslave.com/ CCIE #23115 (RS + Security) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
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 br...@bluecoat93.org wrote: From: Brian Landers br...@bluecoat93.org Subject: Re: [c-nsp] QoS on ingress To: Heath Jones hj1...@gmail.com Cc: cisco-nsp 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 (RS + Security) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
I just went back and reviewed the material from Cisco Live, and the stated goal of reverse ingress shaping (as Cisco calls it) is to protect critical UDP traffic (e.g. VoIP) from TCP congestion by creating effectively an inbound priority queue. You shape inbound TCP traffic to 85-95% of the link speed to protect VoIP calls at teleworker locations (or other sites where you don't have ISP-provided QoS). At least from the data shown, this is effective at preventing latency/jitter in the UDP traffic. The presenter covered different tests at 85%, 90%, etc. and the effects on UDP traffic. I probably shouldn't share the PDF or audio of the session, but if you have Cisco Live Virtual account I would definitely recommend checking out BRKRST-3500: Designing Multipoint WAN QoS B* -- Brian C Landers http://www.packetslave.com/ CCIE #23115 (RS + Security) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
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 hj1...@gmail.com wrote: From: Heath Jones hj1...@gmail.com Subject: Re: [c-nsp] QoS on ingress To: danger will myni...@yahoo.com Cc: Brian Landers br...@bluecoat93.org, cisco-nsp cisco-nsp@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 myni...@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 br...@bluecoat93.org wrote: From: Brian Landers br...@bluecoat93.org Subject: Re: [c-nsp] QoS on ingress To: Heath Jones hj1...@gmail.com Cc: cisco-nsp 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 (RS + Security) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
On Sat, Sep 11, 2010 at 12:33 PM, danger will myni...@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 ? If you're in an MPLS environment, you should absolutely be making use of the proper markings to stick your VOIP traffic in a dedicated strict priority queue on the PE egress interface. The remote ingress queuing stuff is designe for things like branch offices and teleworkers connected via VPN or some other case where you don't have vendor-provided QoS to manage the inbound flows. B* -- Brian C Landers http://www.packetslave.com/ CCIE #23115 (RS + Security) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
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 myni...@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 hj1...@gmail.com* wrote: From: Heath Jones hj1...@gmail.com Subject: Re: [c-nsp] QoS on ingress To: danger will myni...@yahoo.com Cc: Brian Landers br...@bluecoat93.org, cisco-nsp cisco-nsp@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 myni...@yahoo.comhttp://mc/compose?to=myni...@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 br...@bluecoat93.orghttp://mc/compose?to=br...@bluecoat93.org * wrote: From: Brian Landers br...@bluecoat93.orghttp://mc/compose?to=br...@bluecoat93.org Subject: Re: [c-nsp] QoS on ingress To: Heath Jones hj1...@gmail.comhttp://mc/compose?to=hj1...@gmail.com Cc: cisco-nsp cisco-nsp@puck.nether.nethttp://mc/compose?to=cisco-...@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 (RS + Security) ___ cisco-nsp mailing list cisco-nsp@puck.nether.nethttp://mc/compose?to=cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
On Sat, Sep 11, 2010 at 9:52 AM, Heath Jones hj1...@gmail.com 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 myni...@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 br...@bluecoat93.org* wrote: From: Brian Landers br...@bluecoat93.org Subject: Re: [c-nsp] QoS on ingress To: Heath Jones hj1...@gmail.com Cc: cisco-nsp 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 (RS + Security) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net http://mc/compose?to=cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] QoS on ingress
I can't seem to figure out what to do with my situation, wondering if anyone had encountered this. Situation : Router : 1841 IOS 12.4T or 15.0M Internet T1, two eth Interfaces There are VoIP traffic (SIP RTP) and general internet traffic VoIP provider does not tag SIP/RTP with any kind of QoS in IP header. (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP traffic is not marked, it's not useful. Problem to solve : how to not drop ingress VoIP traffic when internet traffic is high as much as possible without capping the non-VoIP traffic to less than T1 bandwidth. Caveat : I understand that since it's not getting policed at the egress from the provider, any solution is not going to be perfect I can't limit the traffic on the Eth interface egress because traffic can go to either eth interface. Any thoughts? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
Not much you can do as its Fifo. I can't seem to figure out what to do with my situation, wondering if anyone had encountered this. Situation : Router : 1841 IOS 12.4T or 15.0M Internet T1, two eth Interfaces There are VoIP traffic (SIP RTP) and general internet traffic VoIP provider does not tag SIP/RTP with any kind of QoS in IP header. (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP traffic is not marked, it's not useful. Problem to solve : how to not drop ingress VoIP traffic when internet traffic is high as much as possible without capping the non-VoIP traffic to less than T1 bandwidth. Caveat : I understand that since it's not getting policed at the egress from the provider, any solution is not going to be perfect I can't limit the traffic on the Eth interface egress because traffic can go to either eth interface. Any thoughts? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
There isn't much you can do here if your provider isn't willing to play ball. What I would suggest is policing your ingress for all but your voip traffic to about 10% less than your maximum throughput, assuming the majority of your user traffic is tcp this should give you enough overhead for a voip stream or 2 depending on your codec. The last thing you want to do is try and run the T1 to capacity as you are at the peril of your providers egress policy whether that be policing, shaping or just tail drop, either one you don't want for your voip traffic. On Fri, Sep 10, 2010 at 7:44 PM, Jay Nakamura zeusda...@gmail.com wrote: I can't seem to figure out what to do with my situation, wondering if anyone had encountered this. Situation : Router : 1841 IOS 12.4T or 15.0M Internet T1, two eth Interfaces There are VoIP traffic (SIP RTP) and general internet traffic VoIP provider does not tag SIP/RTP with any kind of QoS in IP header. (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP traffic is not marked, it's not useful. Problem to solve : how to not drop ingress VoIP traffic when internet traffic is high as much as possible without capping the non-VoIP traffic to less than T1 bandwidth. Caveat : I understand that since it's not getting policed at the egress from the provider, any solution is not going to be perfect I can't limit the traffic on the Eth interface egress because traffic can go to either eth interface. Any thoughts? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
Jay I know it might sound ridiculously obvious, but is another T1 out of the question? On 10 September 2010 19:44, Jay Nakamura zeusda...@gmail.com wrote: I can't seem to figure out what to do with my situation, wondering if anyone had encountered this. Situation : Router : 1841 IOS 12.4T or 15.0M Internet T1, two eth Interfaces There are VoIP traffic (SIP RTP) and general internet traffic VoIP provider does not tag SIP/RTP with any kind of QoS in IP header. (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP traffic is not marked, it's not useful. Problem to solve : how to not drop ingress VoIP traffic when internet traffic is high as much as possible without capping the non-VoIP traffic to less than T1 bandwidth. Caveat : I understand that since it's not getting policed at the egress from the provider, any solution is not going to be perfect I can't limit the traffic on the Eth interface egress because traffic can go to either eth interface. Any thoughts? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
Well, I don't think another T1 will solve the problem. Someone watching Hulu or something will just suck the bandwidth down. I think what I am hearing is, I just need to suck it up and rate limit non-VoIP traffic to 1.2mbps or something on ingress and hope that's enough head room for VoIP to get through while TCP traffic slows down from the rate-limit. Of course, if all other traffic is UDP, it may not do any good. On Fri, Sep 10, 2010 at 3:14 PM, Heath Jones hj1...@gmail.com wrote: Jay I know it might sound ridiculously obvious, but is another T1 out of the question? On 10 September 2010 19:44, Jay Nakamura zeusda...@gmail.com wrote: I can't seem to figure out what to do with my situation, wondering if anyone had encountered this. Situation : Router : 1841 IOS 12.4T or 15.0M Internet T1, two eth Interfaces There are VoIP traffic (SIP RTP) and general internet traffic VoIP provider does not tag SIP/RTP with any kind of QoS in IP header. (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP traffic is not marked, it's not useful. Problem to solve : how to not drop ingress VoIP traffic when internet traffic is high as much as possible without capping the non-VoIP traffic to less than T1 bandwidth. Caveat : I understand that since it's not getting policed at the egress from the provider, any solution is not going to be perfect I can't limit the traffic on the Eth interface egress because traffic can go to either eth interface. Any thoughts? ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
Correct. If someone wants their pr0n, they will get it either way :) I actually meant a new T1 dedicated for voip.. On 10 September 2010 20:17, Jay Nakamura zeusda...@gmail.com wrote: Well, I don't think another T1 will solve the problem. Someone watching Hulu or something will just suck the bandwidth down. I think what I am hearing is, I just need to suck it up and rate limit non-VoIP traffic to 1.2mbps or something on ingress and hope that's enough head room for VoIP to get through while TCP traffic slows down from the rate-limit. Of course, if all other traffic is UDP, it may not do any good. On Fri, Sep 10, 2010 at 3:14 PM, Heath Jones hj1...@gmail.com wrote: Jay I know it might sound ridiculously obvious, but is another T1 out of the question? On 10 September 2010 19:44, Jay Nakamura zeusda...@gmail.com wrote: I can't seem to figure out what to do with my situation, wondering if anyone had encountered this. Situation : Router : 1841 IOS 12.4T or 15.0M Internet T1, two eth Interfaces There are VoIP traffic (SIP RTP) and general internet traffic VoIP provider does not tag SIP/RTP with any kind of QoS in IP header. (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP traffic is not marked, it's not useful. Problem to solve : how to not drop ingress VoIP traffic when internet traffic is high as much as possible without capping the non-VoIP traffic to less than T1 bandwidth. Caveat : I understand that since it's not getting policed at the egress from the provider, any solution is not going to be perfect I can't limit the traffic on the Eth interface egress because traffic can go to either eth interface. Any thoughts? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
Ingress QOS may not help here even if it was supported on T1's. By the time your router is able to police the traffic it will have already been sent from the provider's edge router. Even if you could prioritize the VOIP traffic at your router it would have already been delayed in the egress queues of the last hop provider router. I would suggest separating the internet traffic onto a different circuit. A T1 seem a bit limited anyway. If your site is truly that small you may get more value out of a service like FIOS or business DSL. On Fri, Sep 10, 2010 at 3:33 PM, Heath Jones hj1...@gmail.com wrote: Correct. If someone wants their pr0n, they will get it either way :) I actually meant a new T1 dedicated for voip.. On 10 September 2010 20:17, Jay Nakamura zeusda...@gmail.com wrote: Well, I don't think another T1 will solve the problem. Someone watching Hulu or something will just suck the bandwidth down. I think what I am hearing is, I just need to suck it up and rate limit non-VoIP traffic to 1.2mbps or something on ingress and hope that's enough head room for VoIP to get through while TCP traffic slows down from the rate-limit. Of course, if all other traffic is UDP, it may not do any good. On Fri, Sep 10, 2010 at 3:14 PM, Heath Jones hj1...@gmail.com wrote: Jay I know it might sound ridiculously obvious, but is another T1 out of the question? On 10 September 2010 19:44, Jay Nakamura zeusda...@gmail.com wrote: I can't seem to figure out what to do with my situation, wondering if anyone had encountered this. Situation : Router : 1841 IOS 12.4T or 15.0M Internet T1, two eth Interfaces There are VoIP traffic (SIP RTP) and general internet traffic VoIP provider does not tag SIP/RTP with any kind of QoS in IP header. (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP traffic is not marked, it's not useful. Problem to solve : how to not drop ingress VoIP traffic when internet traffic is high as much as possible without capping the non-VoIP traffic to less than T1 bandwidth. Caveat : I understand that since it's not getting policed at the egress from the provider, any solution is not going to be perfect I can't limit the traffic on the Eth interface egress because traffic can go to either eth interface. Any thoughts? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
If it cannot be applied as an ingress policy for inbound traffic, then on the egress port of the same router for traffic in the same direction. It's the tcp traffic that would need to be cut down, that atleast can be affected. On 10 September 2010 22:34, Keegan Holley keegan.hol...@sungard.com wrote: Ingress QOS may not help here even if it was supported on T1's. By the time your router is able to police the traffic it will have already been sent from the provider's edge router. Even if you could prioritize the VOIP traffic at your router it would have already been delayed in the egress queues of the last hop provider router. I would suggest separating the internet traffic onto a different circuit. A T1 seem a bit limited anyway. If your site is truly that small you may get more value out of a service like FIOS or business DSL. On Fri, Sep 10, 2010 at 3:33 PM, Heath Jones hj1...@gmail.com wrote: Correct. If someone wants their pr0n, they will get it either way :) I actually meant a new T1 dedicated for voip.. On 10 September 2010 20:17, Jay Nakamura zeusda...@gmail.com wrote: Well, I don't think another T1 will solve the problem. Someone watching Hulu or something will just suck the bandwidth down. I think what I am hearing is, I just need to suck it up and rate limit non-VoIP traffic to 1.2mbps or something on ingress and hope that's enough head room for VoIP to get through while TCP traffic slows down from the rate-limit. Of course, if all other traffic is UDP, it may not do any good. On Fri, Sep 10, 2010 at 3:14 PM, Heath Jones hj1...@gmail.com wrote: Jay I know it might sound ridiculously obvious, but is another T1 out of the question? On 10 September 2010 19:44, Jay Nakamura zeusda...@gmail.com wrote: I can't seem to figure out what to do with my situation, wondering if anyone had encountered this. Situation : Router : 1841 IOS 12.4T or 15.0M Internet T1, two eth Interfaces There are VoIP traffic (SIP RTP) and general internet traffic VoIP provider does not tag SIP/RTP with any kind of QoS in IP header. (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP traffic is not marked, it's not useful. Problem to solve : how to not drop ingress VoIP traffic when internet traffic is high as much as possible without capping the non-VoIP traffic to less than T1 bandwidth. Caveat : I understand that since it's not getting policed at the egress from the provider, any solution is not going to be perfect I can't limit the traffic on the Eth interface egress because traffic can go to either eth interface. Any thoughts? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
If you're trying to effect incoming traffic on the T1 this is even worse. You've now moved from one hop (or more) past the point of congestion to two hops. You will still have congestion on the egress queue of the provider router and possibly the ingress queue of your router as a result. If you can't get your VOIP provider to help I would just us the circuit for VOIP only. Have you looked at your bandwidth usage? 1M seems like a small circuit. I've seen one PC use more than that (yes with legitimate services). On Fri, Sep 10, 2010 at 5:47 PM, Heath Jones hj1...@gmail.com wrote: If it cannot be applied as an ingress policy for inbound traffic, then on the egress port of the same router for traffic in the same direction. It's the tcp traffic that would need to be cut down, that atleast can be affected. On 10 September 2010 22:34, Keegan Holley keegan.hol...@sungard.comwrote: Ingress QOS may not help here even if it was supported on T1's. By the time your router is able to police the traffic it will have already been sent from the provider's edge router. Even if you could prioritize the VOIP traffic at your router it would have already been delayed in the egress queues of the last hop provider router. I would suggest separating the internet traffic onto a different circuit. A T1 seem a bit limited anyway. If your site is truly that small you may get more value out of a service like FIOS or business DSL. On Fri, Sep 10, 2010 at 3:33 PM, Heath Jones hj1...@gmail.com wrote: Correct. If someone wants their pr0n, they will get it either way :) I actually meant a new T1 dedicated for voip.. On 10 September 2010 20:17, Jay Nakamura zeusda...@gmail.com wrote: Well, I don't think another T1 will solve the problem. Someone watching Hulu or something will just suck the bandwidth down. I think what I am hearing is, I just need to suck it up and rate limit non-VoIP traffic to 1.2mbps or something on ingress and hope that's enough head room for VoIP to get through while TCP traffic slows down from the rate-limit. Of course, if all other traffic is UDP, it may not do any good. On Fri, Sep 10, 2010 at 3:14 PM, Heath Jones hj1...@gmail.com wrote: Jay I know it might sound ridiculously obvious, but is another T1 out of the question? On 10 September 2010 19:44, Jay Nakamura zeusda...@gmail.com wrote: I can't seem to figure out what to do with my situation, wondering if anyone had encountered this. Situation : Router : 1841 IOS 12.4T or 15.0M Internet T1, two eth Interfaces There are VoIP traffic (SIP RTP) and general internet traffic VoIP provider does not tag SIP/RTP with any kind of QoS in IP header. (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP traffic is not marked, it's not useful. Problem to solve : how to not drop ingress VoIP traffic when internet traffic is high as much as possible without capping the non-VoIP traffic to less than T1 bandwidth. Caveat : I understand that since it's not getting policed at the egress from the provider, any solution is not going to be perfect I can't limit the traffic on the Eth interface egress because traffic can go to either eth interface. Any thoughts? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
The constraints already laid down are that the link cannot be policed differently between voip non-voip on the provider side. Getting a 2nd link just for voip has been suggested. The idea behind policing as mentioned previously, is to slow down the tcp traffic flowing over the link. Keep in mind how tcp works here, and the logic becomes clear. On 11 September 2010 00:36, Keegan Holley keegan.hol...@sungard.com wrote: If you're trying to effect incoming traffic on the T1 this is even worse. You've now moved from one hop (or more) past the point of congestion to two hops. You will still have congestion on the egress queue of the provider router and possibly the ingress queue of your router as a result. If you can't get your VOIP provider to help I would just us the circuit for VOIP only. Have you looked at your bandwidth usage? 1M seems like a small circuit. I've seen one PC use more than that (yes with legitimate services). On Fri, Sep 10, 2010 at 5:47 PM, Heath Jones hj1...@gmail.com wrote: If it cannot be applied as an ingress policy for inbound traffic, then on the egress port of the same router for traffic in the same direction. It's the tcp traffic that would need to be cut down, that atleast can be affected. On 10 September 2010 22:34, Keegan Holley keegan.hol...@sungard.comwrote: Ingress QOS may not help here even if it was supported on T1's. By the time your router is able to police the traffic it will have already been sent from the provider's edge router. Even if you could prioritize the VOIP traffic at your router it would have already been delayed in the egress queues of the last hop provider router. I would suggest separating the internet traffic onto a different circuit. A T1 seem a bit limited anyway. If your site is truly that small you may get more value out of a service like FIOS or business DSL. On Fri, Sep 10, 2010 at 3:33 PM, Heath Jones hj1...@gmail.com wrote: Correct. If someone wants their pr0n, they will get it either way :) I actually meant a new T1 dedicated for voip.. On 10 September 2010 20:17, Jay Nakamura zeusda...@gmail.com wrote: Well, I don't think another T1 will solve the problem. Someone watching Hulu or something will just suck the bandwidth down. I think what I am hearing is, I just need to suck it up and rate limit non-VoIP traffic to 1.2mbps or something on ingress and hope that's enough head room for VoIP to get through while TCP traffic slows down from the rate-limit. Of course, if all other traffic is UDP, it may not do any good. On Fri, Sep 10, 2010 at 3:14 PM, Heath Jones hj1...@gmail.com wrote: Jay I know it might sound ridiculously obvious, but is another T1 out of the question? On 10 September 2010 19:44, Jay Nakamura zeusda...@gmail.com wrote: I can't seem to figure out what to do with my situation, wondering if anyone had encountered this. Situation : Router : 1841 IOS 12.4T or 15.0M Internet T1, two eth Interfaces There are VoIP traffic (SIP RTP) and general internet traffic VoIP provider does not tag SIP/RTP with any kind of QoS in IP header. (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP traffic is not marked, it's not useful. Problem to solve : how to not drop ingress VoIP traffic when internet traffic is high as much as possible without capping the non-VoIP traffic to less than T1 bandwidth. Caveat : I understand that since it's not getting policed at the egress from the provider, any solution is not going to be perfect I can't limit the traffic on the Eth interface egress because traffic can go to either eth interface. Any thoughts? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS on ingress
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 (RS + Security) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
