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.

Figure 2: MPTCP transparently incorporates several subflows using different interfaces into one session.

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].

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Controlled Delay Management

    The persistent and growing problem of bufferbloat is getting serious relief from a new active queue management tool known as a Controlled Delay – a tool that, thanks to heroic efforts, is now ready for Linux.

  • Security Lessons: Bufferbloat

    An abundance of buffers hides the Internet’s dirty little secret.

  • Linux News
    • Red Hat Addresses Secure Boot
    • FSF Addresses Secure Boot
    • Android 4.1 Jelly Bean
  • News

    In the news: Purism Launches a Mini PC; openSUSE Leap 15.2 Adds AI and Machine Learning; Google's Nearby Sharing Could Work with Linux; System76 Launches Ryzen-Powered Laptop; Fedora 33 Desktop Defaults to Btrfs; and SUSE Acquires Rancher Labs.

  • IoT with RabbitMQ

    Connect multiple protocols and servers together on your IoT projects.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95