scheduler: new callback to initiate optimisations

[matttbe]

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 as "stale", force probing a subflow, etc.), it will need to react quicker and at different moment: e.g. when MPTCP and TCP congestion windows are being updated, typically when ACK are received, and RTO are fired.

It is important not to limit to MPTCP level events but to TCP level events: e.g. when a TCP ACK is received (at subflow level): RTT has maybe changed, maybe the subflow is no longer "stale". This is probably linked to #343.

[sferlin]

When would you add such a callback? As we are talking about updates on the TCP level that happen at least 1x/RTT, by the time, you have RTT measurements on the MPTCP level and you could perform "optimisations" on sub-RTT level. Assuming that the multipath scheduler would operate with some knowledge about the RTT of the subflows, you could have such callbacks operating with this granularity.

Potential corner case: If you want to set a subflow to "stale" and there is data inflight. In MPTCP, (afaicr) you can ack data from different subflows i.e. not only the subflow that has sent the data. This might or might not be a problem, which needs some investigation.

[matttbe]

Hi @sferlin,

For the moment, a new packet scheduler will only be invoked before queuing data and to select the next subflow. That's not enough to take decisions like optimisations, etc. It should be called more often: not regularly (a new scheduler can do that without the help from the core) but in case of events like RTO, subflow events, etc. From there, the scheduler can also record the time since the last optimisation and decide not to do anything, e.g. to do something at a rate of max 1 RTT.

(I'm not sure I'm replying to your question, don't hesitate if I don't)