scheduler: (un)mark a subflow as "stale"

[matttbe]

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. if a subflow is considered as "really bad" by the scheduler (e.g. too high latency, too unstable, etc.) and it should not be used for the moment, the scheduler will want to mark the subflow as "stale" and have a regular probing (linked to #348).

The packet scheduler should either:

• be able to replace what the core is doing
• or managing a new bit field

Because the "stale" bit is tightly linked to the RTO (a subflow will no longer be considered as "stale" by the core and unmarked when a packet has been acked on this subflow), it should because to manage a new bit where only the packet scheduler will be able to mark and unmark it as "temporarily unusable" ("skip this subflow if possible").

[sferlin]

It sounds a bit strange that putting a subflow to "stale" state can be defined from outside the scheduler. Can you provide a bit of context here about why this decision (the sysctl above) was defined like it is? In principle, if the scheduler has the logic of putting a subflow into "stale" state, I would suggest that it can precede what core is doing. Not all schedulers will include this logic, to "discard" (even temporarily) a subflow from the scheduling decision.

[pabeni]

It sounds a bit strange that putting a subflow to "stale" state can be defined from outside the scheduler.

To hopefully clarify: currently subflows are marked (un unmarked) as stale by the build-in scheduler. The main point behind this issue is that currently the MPTCP core does not offer clear APIs to the eBPF scheduler to do such action.

We need to clearly define such APIs, re-factor the core scheduler to used them instead of the current direct suflow struct manipulation and write some eBPF code to leverage such new APIs.

[matttbe]

Following the discussion we had with Mat on the ML, it sounds better for a packet scheduler not to modify the "stale" bit but use a new one, see the new note in the issue description:

Because the "stale" bit is tightly linked to the RTO (a subflow will no longer be considered as "stale" by the core and unmarked when a packet has been acked on this subflow), it should because to manage a new bit where only the packet scheduler will be able to mark and unmark it as "temporarily unusable" ("skip this subflow if possible").