Matthieu Baerts
Matthieu Baerts
Some failures can happen when the PM tries to establish new subflows. Without new MIBs counters, it is difficult to understand what went wrong, as discussed in #331, e.g. one...
Currently, the behaviour of the in-kernel PM is: - send a first `ADD_ADDR` (if any) once the connection switched to "fully established" - send other `ADD_ADDR` (if any) after each...
This is a follow up of the discussions that @pabeni started on #331: https://github.com/multipath-tcp/mptcp_net-next/issues/331#issuecomment-1361552212 If on the server side, the PM has endpoints created with both the flags `signal` and...
We are currently one validating the creation of one MPTCP connection at a time. We don't look at the behaviour of listener sockets having multiple accepts. One particular case that...
The core is currently marking a subflow as "stale" after a certain number of losses (`net.mptcp.stale_loss_cnt`). A packet scheduler might be able to do the same for other reasons: e.g....
This is a "meta" issue: a few API changes and other improvements are needed to improve the current packets scheduler and allow new ones (with BPF). - [ ] #332...
Resources might be limited at MPTCP level (sending/receiving window). Also some terrible subflows can badly impact the performances of the MPTCP subflows. MPTCP has a view of all the different...
Currently, the packet scheduler is only invoked before queuing data and to select the next subflow. If a packet scheduler wants to do some optimisations ("penalisation", "opportunistic retransmissions", mark subflows...
Subflows marked as "stale" should be probed from time to time, e.g. once per RTT if there are data to send, at the end of a batch. Currently, these subflows...
This is related to #368: once this work will be done, we would like to regularly check we don't introduce regressions: new tests (from the export branch) validating new features...