sounded to me like this is a single IP (tcp/udp) connection saturation
scenario, without a serious L7 filter in play its gonna do what its
gonna
do. Powercode for example (historically, not sure about now without
procera)
only applied the cap on new ip connections, established maintained
whatever
it was originally. so if you started an unbroken stream at a 12mb
burst,
that stream always hung out at 12mb, if your sustained was 3mb, new
streams
were limited to 3mb aggregate, but the 12mb stream prevailed as long as
it
was never considered "new". even when powercode was useful with the
throttling controls, before they threw away their primary benefit in
the
bandwidth control area to sell their soul to procera with the real time
throttles they took away. with the limited viability of procera boxes
in
the
open internet era, I can see where this would be a cluster f**k post
12k
investment.
On Tue, Jul 12, 2016 at 9:44 PM, Josh Reynolds <[email protected]>
wrote:
The policer at the network edge can be much more aggressive than a
"policer" on an embedded customer network device, and this prevents
that "15Mbps for a 900MHz customer" bandwidth from transitioning
across your backhauls / backbone... per customer.
Procera and other similar solutions can help, yes.
On Tue, Jul 12, 2016 at 8:02 PM, Ken Hohhof <[email protected]> wrote:
> How does it eliminate the problem, unless you use something like a
> Procera
> to selectively apply policing to the CDN stream, leaving the
> customer
> some
> bandwidth for other traffic?
>
> From: Josh Reynolds
> Sent: Tuesday, July 12, 2016 7:22 PM
> To: [email protected]
> Subject: Re: [AFMUG] CDN overload
>
>
> Shaping/policing at the head end eliminates this problem, and clears
> > >
> up
> your
> backbone.
>
> On Jul 12, 2016 7:06 PM, "Ken Hohhof" <[email protected]> wrote:
>>
>> When this happens it basically wipes out that customer’s Internet
>> except
>> for the CDN download, no matter where you do the rate limiting.
>> Customer of
>> course assumes their ISP just sucks. With a lot of education, you
>> >> >>
>> can
>> convince most of them it is actually an aggressive application >>
>> hogging
>> their
>> entire pipe and pushing all the other applications aside. So I
>> have
>> customers that whenever their VPN to work stops working, they yell
>> upstairs
>> at their kid didn’t I tell you to do your Xbox downloads after I go
>> >> to
>> bed?
>>
>> One view is this isn’t a problem, customer uses bad application, >>
>> feels
>> pain, learns not to do that. But everyone tells them it is always
>> >> >>
>> the
>> ISP’s
>> fault. And people with fat pipes like 50 or 100 Mbps cable
>> Internet
>> probably don’t experience this problem, which reinforces the idea
>> >>
>> that
>> it’s
>> the ISP’s fault.
>>
>>
>> From: Darin Steffl
>> Sent: Tuesday, July 12, 2016 5:42 PM
>> To: [email protected]
>> Subject: Re: [AFMUG] CDN overload
>>
>>
>> Why aren't you rate limiting at the core closer to your upstream?
>> >>
>> Keep
>> the
>> traffic off your last mile and wireless backhaul network if you can
>> help it.
>>
>> Works much better to throttle at the core instead of CPE.
>>
>> Sent from my smartphone. Please excuse any typos.
>>
>> On Jul 12, 2016 5:13 PM, "George Skorup" <[email protected]> wrote:
>>>
>>> I have had it with these CDNs sending more traffic than the last
>>> >>> >>>
>>> mile
>>> can
>>> handle. Got a customer at 1.5Mbps on 900 FSK and they're sending
>>> to
>>> her at
>>> 15Mbps. Of course the AP reports RF downlink overloaded.
--
If you only see yourself as part of the team but you don't see your
team
as
part of yourself you have already failed as part of the team.
