[c-nsp] QoS on ingress

[Heath Jones]

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.holley at 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 <hj1980 at 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.holley at 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 <hj1980 at 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 <zeusdadog at 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 <hj1980 at 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 <zeusdadog at 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 at 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 at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>
>>>>
>>>>
>>>
>>
>