Slight correction, you can virtually do whatever you want, you just
can't really block "legal" things, and have to make a good excuse for
"reasonable network management" if you do.

On Tue, Jul 12, 2016 at 11:15 PM, Josh Reynolds <[email protected]> wrote:
> "limited viability of procera boxes in the open internet era"
>
> You are terribly misinformed.
>
> You can do whatever you want, you just have to put it in some fine
> print somewhere. You also can't discriminate and limit a specific
> service provider. For instance, you can't shape netflix and not hulu,
> but if you wanted to limit each subscriber to "6Mbps Steaming Video",
> there's no problem with that.
>
> Procera boxes are INCREDIBLY useful, and not just for traffic shaping.
> They also make excellent CGNAT boxes, can help substantially with
> DoS/DDoS detection and DoS assistance mechanisms, and give you
> excellent DPI into subscriber usage. Knowing what's in use on your
> network per subscriber is also substantially helpful when trying to
> help a customer with an issue.
>
> support: "You're using all of your bandwidth"
>
> customer: "No I'm not, the kids are in bed and we're not using the
> wifi" (they all call it "the wifi" it seems like)
>
> support: "I see 15Mbps of Steam updates going on right now"
>
> customer: "BRB lemmie shut of my son's computer"
>
> *waits for customer speedtest*
>
> customer: "Hey that looks great, thank you VERY MUCH!"
>
> support: "No problem sir/maam. Glad we could help!"
>
> On Tue, Jul 12, 2016 at 10:44 PM, That One Guy /sarcasm
> <[email protected]> wrote:
>> 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.

Reply via email to