SoylentNews is people
SoylentNews
from the I-have-no-Skype-and-I-must-scream dept.
Submitted via IRC for SoyCow1984
How a phone app detected Sprint's alleged throttling of Skype
The US government killed off its net neutrality rules in June of this year, but that doesn't mean no one is monitoring whether carriers are blocking or throttling online services. Northeastern University researchers led by computer science professor David Choffnes recently determined that Sprint was throttling Skype. Their finding was based on an analysis of user-initiated tests conducted with Wehe, an app for Android and iPhone that the researchers developed to detect throttling. About one-third of the tests detected Sprint's throttling of Skype, Choffnes said.
If the findings are correct, Sprint would be violating a Federal Communications Commission rule requiring Internet providers to disclose throttling. Even though the FCC no longer bans throttling itself, the agency requires ISPs to publicly disclose any blocking, throttling, or paid prioritization. But was Sprint really throttling Skype? Sprint denies it and points out that researchers haven't released the data underlying their conclusions. Choffnes acknowledges that his research has limitations and that he couldn't detect the throttling in the lab. But he's still confident that Skype was getting a raw deal on Sprint's network, and he explained why in an interview with Ars.
(Score: 3, Interesting) by insanumingenium on Friday November 30 2018, @06:46PM
His results were inconsistent across OS and location and individual users, but a significant number of individuals tests were highly suggestive of throttling.
The direct quotes listed from the article make it clear Choffnes' conclusions are far more reserved than the ones the media are running with.
However there are users with differentiation which wasn't disclosed by the providers, and that is worth investigating. If random data to the exact same destination isn't treated the same as structured data taken from samples of these services that is sent immediately before it, that is a sign that something isn't right. And when it affects a significant number of users on one provider and service combination in particular, the idea that they all just had a bad connection for that half of the test only starts to not be a reasonable conclusion. That doesn't make it malicious, but it does need to get IDed and fixed or disclosed.
The only obvious change to the testing protocol I would recommend (beyond enhanced data collection which is covered in the article) would be to randomize the order of the tests as well as the order of the test and control runs to avoid forming any unnecessary patterns. This may already be the case, but it doesn't appear to be to me.