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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4