Test Results in WiFi

In WiFi, the tests with Netperf and normal HTTP requests show an even more irregular image. Depending on the WiFi standard, fq_codel leads to slightly better, but also worse results regarding latency and data rate. fq_codel generally works worse together with higher WiFi bitrates. 802.11n and further developments such as 802.11ac are currently particularly problematic because the algorithm prevents the massively used package aggregation. The performance is affected yet further if uplinks and downlinks are loaded at the same time.

According to these experiences, you can use the FQ CoDel algorithm today in the cellular network without disadvantages. Reducing the latency is clearly noticeable in realistic scenarios. WiFi, however, still requires some tests. Current incompatibilities between the CoDel and WiFi standards mean you should tread carefully until the industry implements better integration of wireless protocols [44].

The MPTCP Failover Test

We focused on the failover scenarios when evaluating MPTCP because the performance when bundling WiFi and 3G through high latency and jitter in the cellular network can come off worse than with an individual connection [45]. Furthermore, operating multiple paths in parallel to activate MPTCP in the Linux kernel is not easy because Android disconnects the mobile data connection in an active WiFi connection. The parallel operation of multiple paths would require reprogramming the network routines. Positively expressed, enabling MPTCP in the Linux kernel is already enough to increase the robustness of TCP connections against the temporary loss of wireless connections.

We initiated a Netperf session for the MPTCP failover test using MPTCP via the WLAN interface. We separated the WiFi connection during data transfer. After establishing an Internet connection via the mobile network, MPTCP then automatically added the 3G connection to the session so that the data transfer continued. The session later switched back to WiFi in the same manner.

Figure 6 shows that, after the WiFi connection is lost, the MPTCP connection can be continued after about 4 seconds with enabled MPTCP using mobile communications. Switching back to WiFi requires a transmission pause of 2 seconds. The switching times can be reduced by the parallel operation of both interfaces or completely eliminated with planned network changes.

Figure 6: The MPTCP failover test with measured downtimes and data rates.

Comparisons of MPTCP connections, each with an individual stream, and pure TCP connections show no significant performance differences. However, MPTCP is – as described – still an experimental protocol that is not included in the mainline Linux kernel and requires the support of both client and server. Furthermore, some firewalls or other middleboxes discard packets with the new TCP option. MPTCP avoids the standard TCP in this case – to do so, it must wait out a timeout, meaning that, in the worst case scenario, it can cause a delay with establishing a connection. We therefore recommend MPTCP only for closed systems.

Conclusions

Recent research shows that more efforts are needed to integrate mobile systems with sufficient performance and robustness on the Internet. Linux offers good approaches here; however, these approaches are not very well known. AQM, in the form of FQ CoDel, provides a more promising candidate against bufferbloat problems. MPTCP is a good solution against connection failures when network switching.

However, the tests show that both approaches can neither fully solve the mobile network problems nor can they readily be used productively. These limitations stem from the lack of CoDel support in the leading network and security equipment in particular, and conservative settings for new TCP options in general.

The measurements in this article have shown that no MPTCP connection can be established in the 1&1 (Vodafone) and Blau.de (E-Plus) mobile communications networks because the necessary TCP option has been removed from the packages. The MPTCP tests work with T-Mobile. Some work must be done before mobile devices work optimally in the network. Until then, administrators and developers for whom the performance of mobile systems is particularly important must set up their own realistic test environments.