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