If I'm being honest, it's partly a failure on the sales end to manage
expectations on wireless ("up to 50mbps" etc), and partly a failure of
tech support to manage the conversation. IMO they need to not let the
customer focus on a speed test result and instead prompt them to talk
about what their actual problems are. Whether the speed test says 10 meg
or 50 meg has no bearing on the fact that you suck of Call of Duty or
that your VPN to the office doesn't want to connect this morning.
I think the idea is just make the speed test show what they want to see
and then we can move the conversation forward. It strikes me as a
viable but lazy and dishonest solution. I'm trying hard to be open minded.
I appreciate all the thoughts on this. Thanks everyone.
On 11/5/2019 8:01 AM, Daniel White wrote:
I've worked extensively with Sandvine and Saisei and this is a topic
that always comes up since it is fairly easy to implement via those
appliances (and easier to implement across multiple speed testing sites).
I don't see it as evil on a best effort connection. Customers
typically are not likely to understand what the results mean and the
only congestion it masks is on your network (which you should be aware
of anyways). You can chalk it up to reasonable network management
practices, as the intent is to show what your connection is capable of
vs. what is available to you at that moment. Furthermore, unless the
speedtest server is on your network, sometimes the issue is on the net
or with the server so further impacting the results by giving the
testing a low availability on your network is further giving your
customers the wrong impression of your actual delivery.
By implementing something though - how many support tickets are you
potentially reducing? How about customer churn? If these are issues
for you is it because you have actual congestion on your network? Is
hacking the response worthwhile from a technical effort - and if your
customers found out about it is it worthwhile from a PR standpoint?
I usually end up somewhere in the it's cool to tinker with but of
limited value in the real world. The PR fallout if your competition
finds out and uses it against you is probably more damaging.
My 2 cents.
photograph
Daniel White
Co-Founder & Managing Director of Operations
phone: +1 (702) 470-2766
direct:+1 (702) 470-2770
Adam Moffett wrote on 11/4/19 12:32:
I can set a higher priority DSCP value on speedtest.net traffic. I
tested this on one SM and it works great. On a busy AP at 9:30pm I
was getting speedtest results from 12-20mbps. I set the speedtest
traffic to DSCP 26 and enable a "medium" priority channel and now
it's 34mbps every single time without fail (and at my data rate,
frame size, etc that's all I could ever hope for).
The question is: Would this be evil?
The feeling is that for some customers there's nothing actually wrong
except they run speedtest.net simultaneously as their XBox downloads
a game and then call to report "slow" speeds. The feeling is that it
would be easier to just let them see a bigger speed test number than
to educate them (and some will always refuse to be educated).
The evil part is that it would mask an actual congestion problem.
There's also a notion being tossed around the office that our
competitors are already doing this. I have no idea if they actually
are, and I'm also not sure if I care what they're doing.
-Adam
--
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
