Procera prevented problems like this from happening. On Mar 28, 2016 9:22 PM, "Ken Hohhof" <[email protected]> wrote:
> It’s not really that the AP or SM is choking, it’s that the rate limiting > process has to throw away most of the customer’s traffic. > Indiscriminately. So the customer thinks his Internet has high packet loss. > > The only thing I can think of that I could do is modify the rate limiter > parameters somehow, like the buffer depth or something. > > It just seems so strange, doesn’t Youtube upload just use HTTP or HTTPS? > Not sure why TCP congestion control wouldn’t apply. > > > *From:* Kurt Fankhauser <[email protected]> > *Sent:* Monday, March 28, 2016 8:54 PM > *To:* [email protected] > *Subject:* Re: [AFMUG] Youtube upload bandwidth > > I ran into this issue on the download side a couple times, when you rate > limit at the Canopy SM and twice the limit is hitting the AP the customer > WILL COMPLAIN about extreamly slow download speeds and high latency. I > confirmed this with one customer and its painfully slow. I had to induce > the rate limit somewhere before the AP so that the SM wouldn't be choking > so bad. > > On Mon, Mar 28, 2016 at 8:11 PM, George Skorup <[email protected]> wrote: > >> That's the way it works. SM controls the uplink, AP controls the >> downlink. The same thing happens in reverse with streaming. Torching a >> customer might show he's pulling 15-18Mbps download when in fact the AP is >> limiting his downlink to 12Mbps per the configured QoS and discarding the >> extra garbage. Because you're looking at what's happening downstream of >> where the throttling is taking place. That's what I see all the time with >> the streaming crap. And we use only the built-in QoS on Canopy. >> >> So in your situation, yes, if you set the customer's SM QoS to throttle >> at 2Mbps sustained uplink, then you will see only 2Mbps exiting the AP's >> ethernet interface for that customer. At least you keep that extra crap off >> of the air. And it's not cosmetic, that's real traffic over the air. Which >> seems totally stupid when that's not how TCP was intended to work. Sure, >> everyone just go ahead and mangle the protocols however you want. It's like >> the DDoS bullshit. I'm fucking tired of it. Sorry for my rant.. I'll go >> back to my hole now. >> >> On 3/28/2016 6:26 PM, Ken Hohhof wrote: >> >> In this case the SM QoS is set to 5M up, 15M down.� The SM is letting >> 5M through, then the tower router is chopping it down to 2M which is the >> plan he is on.� I may have to set the SM limit lower.� I don�t like >> to do that because the router rate limit is set automatically via PPPoE >> from the RADIUS database, whereas the SM limits are set manually. >> >> � >> >> *From:* Af [mailto:[email protected] <[email protected]>] *On >> Behalf Of *George Skorup >> *Sent:* Monday, March 28, 2016 6:15 PM >> *To:* [email protected] >> *Subject:* Re: [AFMUG] Youtube upload bandwidth >> >> � >> >> Where is your bandwidth control? SM or MikroTik? I'm guessing upstream >> router. If you had it on the SM, you wouldn't see the overload. >> >> On 3/28/2016 6:11 PM, Ken Hohhof wrote: >> >> I had a customer today uploading for 2 hours at way over his rate limit, >> he says he was uploading a Youtube video.� Anyone here familiar with the >> Youtube upload process?� Why was it not invoking TCP congestion control >> and instead trying to ram 5 pounds of data through a 2 pound pipe? >> >> � >> >> >> >
