Net neutrality is the idea that Internet service providers (ISPs) should not differentiate between applications and services.
Currently, network operators justify using traffic management techniques that differentiate traffic (for example, video management) to protect their infrastructure from bandwidth-hungry applications. However, regulators, content providers, and consumers worry that these techniques may harm consumers’ online experience and create unfair service competition.
Regardless of your view, transparency is vital for stakeholders to make informed decisions about an acceptable traffic management technique.
To fill this need, a team led by researchers at Northeastern University developed Wehe — an app available from the Google Play and Apple App stores — which allows Internet users to test for instances where traffic of a particular application has been differentiated.
Wehe detects traffic differentiation by replaying a pre-recorded application trace, followed by a bit-inverted version designed so that ISPs do not recognize it. Then, it statistically tests and reports if the throughput of the two replays is significantly different.
Since 2017, Wehe users have run more than 2 million tests, allowing researchers, decision-makers, and Internet users to identify differentiation practices worldwide and understand their implications and harms.
WeHe𝕐: Wehe+localization
A significant limitation of the first version of Wehe was that it only reported that differentiation existed but did not confirm if the access ISP was solely responsible. To fill this gap, our team at the Network Architecture Lab at EPFL collaborated with Northeastern University’s Wehe team and Measurement Lab and designed WeHe𝕐.
WeHe𝕐 localizes traffic differentiation incidences reported by Wehe using the following steps:
- First, it simultaneously replays Wehe’s traces over two network paths that start at different servers, end at the client, and converge exactly once within the access ISP (Figure 2). The two paths need to converge only within the access ISP so that the access ISP can not share the blame with any other ISP. As you can see in Figure 2, this pair of paths forms a “Y” topology, giving rise to the name of our system: Wehe+Y, or WeHeY for short.
- Then, it applies Wehe’s throughput test to confirm differentiation on both paths.
- If both paths report differentiation, WeHe𝕐 looks for evidence that the application traffic, simultaneously sent along the two paths, traversed a common rate-limiter that performs differentiation. Rate-limiters are implemented as queues with low, pre-configured rates. Traffic crossing the rate-limiter experiences lower throughput and higher loss/delay, referred to as traffic throttling. This is the typical way ISPs deploy traffic differentiation.
Detecting a common rate-limiter
WeHe𝕐 detects two kinds of rate-limiters. The first is based on the current practices ISPs deploy, where the client’s application traffic is throttled separately from all the other traffic in the network. We refer to these as per-client rate-limiters. The second is a generalized form of the first, where the network collectively throttles an application’s traffic independently of its destination. We refer to these as general rate-limiters.
WeHe𝕐 detects per-client rate-limiters by comparing the total throughput achieved by a single and pair replay. If the difference between the two is low – compared to standard network conditions, then WeHe𝕐 concludes that the access ISP applies per-client rate-limiting.
We tested a prototype of WeHe𝕐 for five popular U.S. ISPs that disclose rate-limiting video traffic, and WeHe𝕐 successfully localized differentiation in four of them with 85% accuracy (Figure 3). It found no evidence for the fifth ISP because the latter applies delayed rate-limiting; we plan to fix this by using the throughput samples collected after rate-limiting kicks in.
WeHe𝕐 detects general rate-limiters by statistically testing if the loss trends of traffic sent along the two paths are correlated. The rationale is that packets traversing the same queue should see similar packet drops (if any), so their loss trend is correlated (Figure 4. a). Otherwise, they will not observe the same loss events, and their loss trend will not be correlated (Figure 4. b).
We evaluated WeHe𝕐’s loss-trend correlation algorithm using simulation and emulation under different network conditions and configurations. We saw that WeHe𝕐 only fails to find evidence to localize under abnormally high loss (>20%); however, such high loss is infrequent in practice.
The current state of WeHe𝕐
We’ve built and tested our WeHe𝕐 prototype on our own devices, and we are currently working on modifying all Wehe clients to support these tests. As part of our efforts on this project, we provided an exciting new feature for anyone interested in analyzing Wehe(+Y) data: all test data collected by WeHe(𝕐) is now publicly available in BigQuery, thanks to support from M-Lab. We will develop sample queries, analyses, and reports on our findings, so stay tuned to the Wehe and M-Lab websites for updates.
Zeinab Shmeis is a PhD Candidate at EPFL, advised by Katerina Argyraki. Her research interests are Internet Neutrality, Internet measurement systems, and network performance.