Speeding up mobile networks with FQ CoDel and MPTCP
AQM and CoDel
Active Queue Management (AQM) with the Controlled-Delay Algorithm (CoDel) appears to be a viable solution for bufferbloat.
AQM algorithms generally monitor the queue length of network interfaces and automatically discard packets before the queue becomes too long. This behavior signals to the transmitter's TCP implementation that it should restrict the sending data rate due to the imminent overload. The short wait time also improves the response time for TCP error handling ([9], p. 59).
As early as 1998, the Internet Research Task Force provided information about the need for AQM and promoted the Random Early Detection Algorithm (RED) on routers as a solution ([23], p. 2). However, RED and its successors show weaknesses in some situations and also require expert knowledge ([24], p. 1, [9], p. 63). A disadvantage for some experts is that AQM algorithms use the queue length as an indicator of overload, which many people see as ineffective [25].
The CoDel Algorithm, on the other hand, tries to manage without adjusting screws by using the packet's resting time in the queue as an indicator of an overload. ([24], p. 6). Specifically, a constant target
defines the acceptable, constant waiting time during a period interval
.
If the minimum waiting time during a whole interval exceeds target
, CoDel discards the next packet to be sent. Unlike the tail-drop mechanism, which discards incoming packages, discarding outgoing packets allows package losses caused by gaps in the TCP sequence stream to be identified more quickly because subsequent packets do not have to pass through the queue first. CoDel successively discards more common packets until the wait time is again below the target value target
([24], p. 6).
The target
should be chosen so that the wait time is minimized, but so enough room still exists for data traffic spikes. A good value for interval
, which gives the transmitter enough time to react to package losses, is the highest expected RTT.
A target
of 5 milliseconds works well in most situations; lower values can reduce the throughput and higher values do not change anything. An interval
of 100 milliseconds is suitable for RTTs from 10 to 1000 milliseconds, with an optimum performance from 10 to 300 milliseconds ([24], p. 6).
CoDel does not manage completely without parameters; however, the default values cover most situations. Simulations have shown that the performance of CoDel is just as good as that of RED – even better in some cases, especially with highly dynamic data rates ([24], p. 7). An unmodified version of CoDel [26] is not, however, suitable for extreme situations, such as use in the data center or on very large routers.
FQ CoDel, BQL, and TCP Small Queues
Interactive communication methods with package types with small size, such as ACKs, DNS requests, SSH, HTTP requests, ARP, ICMP, and VoIP, can also be favored with FQ CoDel, a combination of CoDel and fair package scheduling [27]. FQ CoDel also assigns its own queue to each flow – a data stream with packages whose source (address and port), target (address and port), and protocol (TCP or UDP) are the same.
The scheduler differentiates between old and new flows and prefers to send packets from the new flows. A flow is usually seen as new until it has transmitted an Ethernet frame to data. The scheduler deletes old flows when their queues are empty, and it prefers to treat the next packages of this flow as a new flow.
CoDel and FQ CoDel work at the IP layer and can be implemented in both software and hardware ([24], p. 14). Both have been available in the official Linux kernel since kernel 3.5 [28]. The solution also includes a buffer for traffic control on other protocol layers: The Linux developers have implemented byte queue limits (BQL [29]) within CoDel. These limits control queues at the Ethernet drivers levels and also help CoDel achieve more effectiveness [26]. TCP inserts small queues [31] above CoDel. These queues prevent applications from writing to much data in their socket buffer.
The combination of these techniques effectively reduces bufferbloat. However, many network devices, such as cable and DSL modems, do not provide the possibility to enable AQM (at least, not for the end user) ([24], p. 14). AQM has not prevailed in mobile devices so far because the package aggregation buffer and the error correction are located in WiFi and the cellular layer that the AQM algorithms cannot access.
Multipath TCP
Wireless connections typically work less reliably than wired connections. However, many mobile devices – especially smartphones – can work with more than one wireless technology; WiFi and a mobile interface are common.
The presence of two connection technologies does not help much in standard TCP because each interface has its own IP address and the protocol uses the 4-tuple from the source and the target to identify a connection.
Transparent handovers between the two infrastructures are theoretically possible but are very rare [32]. Mobile IP is another way to maintain the connections, but it also reduces performance and requires extra hardware and software [33] [34]. The protocol expansion Multipath TCP (MPTCP) is a better way. MPTCP tolerates both IP address changes and multiple connections at the same time.
Two MPTCP-enabled endpoints are capable of establishing an MPTCP connection with several subflows. A subflow is regarded as a normal TCP connection. The example is the MPTCP session of a mobile device connected via WiFi: While establishing the first subflow, the MPTCP capability is checked and cryptographic keys exchanged. The mobile device can add more subflows to the connection by establishing a connection to the same server using the mobile network.
The MPTCP protocol sends the newly generated cryptographic keys as an authentication feature in order to ensure data security and protection. Both endpoints can generate or remove subflows at any time, and they distribute the traffic to the subflows at their own discretion. It is conceivable that the mobile device establishes a second subflow immediately to minimize the switching time in the event of a fault and to bundle both connections for a better data rate. If the mobile device pursues the strategy of conserving battery power, it might perhaps established a second subflow if the WiFi connection is interrupted.
As Figure 2 illustrates, MPTCP strives to be compatible with the current Internet. On one hand, MPTCP is transparent to applications, so that the support in the operating system network stack is sufficient for MPTCP. On the other hand, the subflows – apart from a new TCP option – behave just like normal TCP connections in order to be allowed through firewalls and middleboxes. This feature is necessary because these devices change TCP sequence numbers and IP addresses, terminate connections when gaps appear in the sequence number order, and discard packets that use unknown TCP options.
MPTCP implements features to address these challenges: Each subflow contains an individual TCP sequence number order (SSN), which depicts the protocol for the sequence order of the MPTCP session (DSN). Furthermore, MPTCP references interfaces with IDs instead of IP addresses, checks whether the subflows are usable, and discards those that are not. If MPTCP cannot establish a connection, the protocol falls back to standard TCP.
MPTCP promises better support for mobile systems, but it is still an experimental Internet standard. Patches that implement MPTCP in Android and the Linux kernel are available, but they are not part of the mainline kernel [35] [36] [37]. MPTCP is mainly found in closed systems because the receiver and transmitter must be MPTCP-compatible. For example, Citrix uses the technology on its NetScaler platforms and Apple uses MPTCP to transfer data between I-OS 7 devices and Siri servers [38] [39].
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.