And the CDNs don't care. They instead blame the evil ISP.
On 3/28/2016 9:22 PM, Ken Hohhof 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 <mailto:[email protected]>
*Sent:* Monday, March 28, 2016 8:54 PM
*To:* [email protected] <mailto:[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]
<mailto:[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] <mailto:[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?
�
