Is your headend a shack? :)
On Wed, Jul 13, 2016 at 7:06 AM, Ken Hohhof <[email protected]> wrote: > I wish they made a box that didn't need a data center environment. Not > looking forward to putting in an outdoor enclosure with HVAC. > > -----Original Message----- From: Josh Reynolds > Sent: Tuesday, July 12, 2016 11:17 PM > > To: [email protected] > Subject: Re: [AFMUG] CDN overload > > 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. > > >
