If the CDN is not delivering traffic following normal TCP guidelines then I consider it Malicous traffic and you have rights to block it. Also +1 on the Procera for diagnosing customer calling saying connection is slow, have used it many times to determine an XBOX update was hogging entire connection. I try to give the problem applications less bandwidth but lately I am leaning towards trying to get more bandwidth to the customer to eliminate these problems altogether.
On Wed, Jul 13, 2016 at 11:45 AM, Josh Reynolds <[email protected]> wrote: > Don't have a decently sized tower hut there with HVAC? > > On Wed, Jul 13, 2016 at 10:43 AM, Ken Hohhof <[email protected]> wrote: > > Tower. > > > > -----Original Message----- From: Josh Reynolds > > Sent: Wednesday, July 13, 2016 10:15 AM > > > > To: [email protected] > > Subject: Re: [AFMUG] CDN overload > > > > 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. > >> > >> > >> > >> > > > > >
