31 Jan 2021
In the description of the multipath implementation in Picoquic, I mentioned that I struggled with the absence of multipath support in the “QLOG” format and the associated tools. Maybe the developers have been spoiled with too many good tools, but we came to rely on tools like “qvis” (https://qvis.edm.uhasselt.be/) to visualize the logs of QUIC connections, showing for example nice graphical representations of the flows of packets. But those tools are not designed for handling packets sent over multiple paths, especially when packet number spaces are specific to each path. When I try to feed a multipath trace into QVIS, the result is a confused mess.
The image above shows what I get when using the "sequence" option in QVIS to the QLOG of a multipath connection. In theory, the vectors join the point in time when a packet was sent to the point in time when it was received, left to right for messages sent by clients, right to left for messages sent by servers. The algorithm evaluates sending and receiving time solely based on packet sequence numbers, and we see errors such as matching the sending of packet #0 on path 1 with the receiving of packet #0 on path 0. Similar issues happen when using the "congestion" options, with congestion signals for path 0 and path 1 conflated on the same sets of erratic lines.
I discussed this with Robin Marx, who developed the QLOG format and the tools. He suggested a simple modification to the QLOG format: when logging events in the log, document the number of the path as part of the event header. That seems like a very good idea, and I have since implemented it in the Picoquic code. It is also the first step towards better visualizations, such as plotting congestion control graphs separately for each path, or matching sending and receiving events per paths in the ladder diagrams. I trust that Robin Marx will soon fix that, and that we can go on easily using QLOG for debugging issues with QUIC multipath.