Beyond the byte stream: qlinq and MPTCP

An application may send data that must arrive in order, updates that can become stale, and content worth protecting with extra repair traffic. Each places different demands on delivery and recovery.

MPTCP combines multiple network paths behind TCP’s reliable, ordered byte stream. qlinq lets applications select reliable streams, datagrams or coded recovery for each named stream, matching delivery behavior to the data they send.

How MPTCP works

MPTCP builds one connection from several ordinary TCP subflows. It can aggregate capacity or keep a connection alive as traffic moves between networks, while preserving the byte-stream interface applications already use. If multipath negotiation fails, it can fall back to ordinary TCP. ¹

Two decisions sit behind that interface. The path manager decides which subflows to establish and which addresses to advertise. The scheduler chooses which available subflow carries data. Linux supports kernel and userspace path management; changing path policy does not require rewriting the application protocol. ²

Ordering remains connection-wide. A slower path can contribute capacity while delaying bytes needed before later data can reach the application. Reinjection over another subflow can help, but the receiver still presents one ordered stream. Applications can separate traffic across multiple MPTCP connections.

MPTCP has shipped upstream since Linux 5.6, many distributions enable it, and tools such as NetworkManager and application wrappers can simplify adoption. Load balancing needs care: additional subflows must reach the same backend, which ordinary connection hashing may not ensure. The Linux project documents deployment options. ^{2 3}

For applications carrying several kinds of data, delivery requirements can vary even when the network paths are the same. qlinq lets those differences guide how each stream handles ordering and recovery.

An alternative approach with qlinq

qlinq offers four delivery policies through one application API:

• Reliable: deliver commands or records in order through a QUIC stream, without imposing that ordering on unrelated streams.
• Datagram: accept missing updates when subsequent updates remain useful, avoiding retransmission of old data.
• Fixed FEC: spend bandwidth upfront on forward error correction, sending repair symbols alongside data to recover some losses without waiting for feedback.
• Rateless: send source data first, then generate repair in response to reported loss, accepting the feedback delay.

Separate streams still share congestion and processing resources. Coding costs bandwidth and CPU; its benefit depends on the loss pattern and recovery policy.

qlinq puts these choices and path allocation in a library shipped with the application. The application team can version, test and deploy its transport implementation alongside the application. Both ends need compatible qlinq software and usable UDP paths, and the team takes responsibility for building, updating and operating that transport.

The comparison

In the same-host comparison using qlinq’s benchmark examples at 100 Mbit/s over unequal paths, both transports delivered every offered record. qlinq reduced the median per-run 99th-percentile delay from 71.63 ms to 41.19 ms, a reduction of about 42%, at higher measured endpoint CPU cost.

The comparison measured application-visible record delay using one reliable qlinq stream and one MPTCP connection protected with TLS. The qlinq test uses no FEC; it does not measure the benefits of coding or independent streams. ⁶

Each trial offered paced 8 KiB records for 60 seconds on equal and unequal paths. The table shows medians across runs, with every pair ordered MPTCP / qlinq. P99 is the 99th-percentile delay from scheduled record generation, including waits for the transport to accept a record.

Both delivered every admitted record in all 26 trials. At higher loads, MPTCP did not accept every offered record before the offering interval ended; that shortfall reflects backpressure, rather than loss of accepted data.

These are same-host configuration comparisons: qlinq used Reno and a 100-packet initial window; MPTCP used CUBIC and the default scheduler. Startup windows and memory accounting differed.

Repeat it from GitHub

Use Linux with MPTCP and network namespace support, sudo access and qlinq’s build prerequisites. The example README lists the required Linux tools and measurement details.

git clone --recurse-submodules https://github.com/ursoid-tech/qlinq.git
cd qlinq/examples/mtcp
./build.sh

Run each transport on the same equal-path profile:

sudo ./lab.sh up mptcp equal
sudo ./run.sh records 180M 60
sudo ./lab.sh down

sudo ./lab.sh up qlinq equal
sudo ./run.sh records 180M 60
sudo ./lab.sh down

For unequal paths, substitute unequal in setup and 100M or 120M in the run command. To match the comparison, repeat each transport three times at unequal/100M and five times at unequal/120M and equal/180M.

qlinq brings reliable, loss-tolerant and coded delivery into one application API, alongside multipath scheduling. Its reliable mode also delivered lower record latency in these tests, with higher measured CPU use. For applications combining ordered commands, frequently refreshed state and data needing repair, qlinq lets each stream use the delivery policy its data calls for. The runnable examples provide a starting point for evaluating reliable delivery on your own workload.

Whether delivering AI or superintelligence models, container images, media streams, telemetry or firmware images, qlinq can serve as a more flexible alternative to MPTCP, with delivery and recovery policies tailored to each stream.

References