Path selection during multipath

[Milind-Blaze]

Hi, I am currently trying to understand the multipath behaviour of picoquic in order to modify it for my own project. I see some documentation in picoquic_internal.h about path behavior (linked here) with a couple of TODOs that seem old. Is this the current path behaviour or has that changed? Also, is there some documentation/guide to understanding the multipath behavior of picoquic? It would be great if someone could please point me to that! Thanks!

[huitema]

This is a correct description... but only if multipath is not negotiated. Yes, it would be nice to document path selection and multipath -- PRs are welcome. Waiting for that, your best bet is to look at the code of picoquic_select_next_path_mp in sender.c and the comments at lines 3978..4043.

[huitema]

There are really two parts in scheduling.

Given the option to "prepare a packet", picoquic has to find a path that is ready to send something, and then find what to send on that path. Find the path is done in picoquic_select_next_path_mp, find what to send is done in picoquic_prepare_packet_ready. The two are actually tied, but the ties are implicit:

• picoquic_select_next_path_mp checks which path could send something if given the turn, whether acknowledgement or data. It checks whether congestion control will allow sending of data, whether pacing will allow sending ACKs, which path has the lowest delays if ACKs need to be sent. It combines that with the status of the path, available or standby, and with the state of the path, nominal or experiencing losses. It tries to ensure that all paths are used.

• picoquic_prepare_packet_ready looks for what messages can be sent on the path based on pacing and congestion control, selects which stream has the highest priority on that path, whether there are control messages to send, etc.

I am testing the new version of multipath proposed in the IETF, and doing that I found an issue when we have two paths, one on standby and one marked available. It takes some time to notice that the "available" path has disappeared. The server finds first, because data packets are lost. But the client does not notice immediately, keeps sending ACKs on the "available" path. The ACKs are lost, and that cause packets sent on either path to be dropped. Both paths are then considered equally bad, scheduling gets confused, and the connection breaks. Fixing that will probably require fixing the was scheduling is done.