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? > > � > > >
