We had several complaints about this yesterday too.... On Thu, Jul 14, 2016 at 8:13 AM, Nate Burke <[email protected]> wrote:
> I just ran into this yesterday, took down an FSK AP that was running at > 10mb Ethernet. A customer with 2 computers, MS Updates running in the > background. Had about 50 http sessions open to 13.x.x.x addresses. > > On 7/14/2016 7:50 AM, Adam Moffett wrote: > > Seems like they (MS) should look into promoting a multicast network for > distributing updates. > > Or simply limit automatic background updates to 256k (per destination). > If the user clicked the update button, sure get it to run as fast as > possible, but if it's in the background and they don't even know it's > happening then it ought to not matter how long the download takes. > > ...of course MS is not likely to care about my opinion on the matter. > > > ------ Original Message ------ > From: "George Skorup" <[email protected]> > To: [email protected] > Sent: 7/14/2016 2:33:21 AM > Subject: Re: [AFMUG] CDN overload > > > I forgot about this. Yes. A little later in the day, I started to see a > lot of 13.n.n.n sources. Microsoft. Yeah, update Tuesday. Then the same > customer would start receiving from LLNW. Then Akamai. And back to MS > again. So it looks like they're *still* distributing updates across various > CDNs. And believe me, it's not like they were all hitting this customer at > once. One single CDN would try to send at 5-10X the customer's downlink > MIR. Sometimes more. At one point I saw over 20Mbps for 5-10 minutes. I saw > pretty much the same thing with about 15 other customers that I looked at. > And they were spread across 5-6 towers. Some directly licensed fed, others > farther towards the edge. > > DDoS. CDN. Same thing. Or gorilla tactics at the very least. If the > customer calls and says "none of my other shit works, your internet sucks" > what are we supposed to do? Oh OK, here, we'll turn you up to 12Mbps and > see what that does. Yeah screw that because now the CDN is sending at > 40Mbps! They need to stop fucking with TCP already! And no, it doesn't > matter where I put the policing/shaping. They still eat up bandwidth on our > upstreams. Like you said before Ken, yeah, it just moves the problem > somewhere else. > > On 7/13/2016 11:39 PM, Ken Hohhof wrote: > > George, did you identify the application or content provider, or only the > CDN? > > I think I started getting hit with the same thing early yesterday > afternoon. At first I thought I was getting DDOS attacks. > > > *From:* George Skorup <[email protected]> > *Sent:* Tuesday, July 12, 2016 6:21 PM > *To:* [email protected] > *Subject:* Re: [AFMUG] CDN overload > > Yup. LLNW. > > On 7/12/2016 5:35 PM, Ken Hohhof wrote: > > I assume you torched the traffic and verified it is all coming from a > particular CDN, not a random bunch of IPs as would be the case with BT. > Since this isn’t your first rodeo. > > *From:* George Skorup <[email protected]> > *Sent:* Tuesday, July 12, 2016 5:31 PM > *To:* [email protected] > *Subject:* Re: [AFMUG] CDN overload > > Because they dick with TCP. > > On 7/12/2016 5:23 PM, Eric Kuhnke wrote: > > And why is it the fault of the CDN? It could be a customer with a > 100-peer bittorrent session downloading 30GB of Ubuntu DVD ISOs. > > On Tue, Jul 12, 2016 at 3: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. >> > > > > > > >
