MPTCP vs QUIC multipath extension performance results

[BertramShell]

Hello!

I would like to share some results I have measured.

• I am experimenting on a small emulated setup with two 10Mbit paths on the client and one 100Mbit path on the server.
• I am transferring a 10MB file using quicperf for PicoQUIC and mptcpize with netcat for MPTCP.
• I am using 2 Fedora 41 machines with the newest MPTCP version and I am using Picoquic (v1.1.29.1).

The delay is the same on both paths. No packet-loss is emulated.

I am using CUBIC on PicoQUIC and MPTCP is set to default in all settings.

As you can see in the plot attached, MPQUIC seems to perform better on average. There is quite a big difference in upload whereas a small difference in download. I have been examining the pcaps and qlogs; however, I am unsure why this might be happening.

In baseline measurements with TCP vs QUIC, TCP strongly outperforms QUIC, which I assume is mainly due to optimizations in the kernel, no encryption and less overhead for TCP.

I am wondering what improvements in MPQUIC manage to catch up to MPTCP and especially outperform it in upload.

Moreover, looking into the qlogs it seems MPQUIC has considerably more retransmissions and packet-loss than MPTCP.

I hope this can help with further development.

[huitema]

The small differences between MPTCP and QUIC multipath are expected. Small issue on the name: the draft specification is titled "Multipath Extension for QUIC" and never uses the acronym MPQUIC, very much by design. QUIC multipath is just QUIC with extensions, not a separate protocol.

QUIC has a bit more overhead than TCP:

• QUIC uses encryption, and encryption creates a bit of overhead -- at least 16 bytes per packet
• QUIC is designed to multiplex multiple stream, while TCP carries just one stream. That too create a bit of overhead, maybe 4 bytes per packet.
• The QUIC header includes a "connection identifier", used for example to manage load balancers in server farms, handle NAT rebinding, and distinguish packets arriving on different paths. Picoquic by default uses 8 bytes for the CID.

With fixed parts of the QUIC header, that sums up to per packet overhead of 8 bytes for the UDP header, plus about 32 bytes per packet. The basic TCP header is only 20 bytes, so for a 1500 bytes packet QUIC has perhaps 0.8% extra overhead. But MPTCP has its own overhead, using TCP options, so the difference should not be too large.

There are other differences between QUIC Multipath and MPTCP. MPTCP uses separate TCP connections, and merges the data at the endpoint. QUIC multipath uses a single connection, and spreads the data over multiple paths. QUIC Multipath can send the ACKs for one path through another path, typically the shortest path; this provides faster feedback when the paths have different latencies. QUIC Multipath will also repeat lost data on any available path, which makes for faster corrections.

The experience above uses two identical paths. It would be nice to repeat it after adding some kind of asymmetry, such as for example adding competing TCP traffic on one of the paths. We might get more insignt on how each solution reacts.

To understand better, we would need traces. The normal tracing tool for QUIC is by using qlog. We have a bit of an issue there, because the most used qlog visualization (qvis) is not capable of visualizing connections that use multiple paths. But there is hope. Qlog uses a JSON syntax, and it is not very hard to write tools that parse JSON and do graphs, etc. See for example qlogparse.py in the picoquic_ns depot, which is designed to graph multiple connections. If someone could contribute something like "qlog parse multipath", that would be great!