Client: fallback to TCP after X MPC
matttbe opened this issue · 2 comments
matttbe commented
MPC packets could be explicitly dropped or reset by firewall somewhere in the network, e.g. with:
iptables -t filter -A FORWARD -p tcp --tcp-option 30 -j DROP
It sounds safer to fallback to TCP after X attempts (defined in a sysctl option?), "just in case".
Later, this could be improved with a cache, see #57.
matttbe commented
From the last weekly meeting:
- it seems really needed because in some places packets having unknown options are dropped: it has been seen (but we don't have figures showing how frequent it is)
- recommendations:
- try 5 times (when using
net.ipv4.tcp_syn_linear_timeouts
), then fallback to "plain" TCP - use a cache technique to avoid doing that all the time, e.g.:
- TFO was caching issues per destination, using tcp-metrics
- but now it just stops for a period of time because "the issues are certainly on the client side"
- see how
tfo_active_disable_times
is used: https://elixir.bootlin.com/linux/latest/A/ident/tfo_active_disable_times
- try 5 times (when using
matttbe commented
From the last weekly meeting:
- that seems important if MPTCP is used by default on the client side
- but probably hard to have it backported
- important to have a sysctl to control the blackhole + an easy way to check if this feature is available
- fallback cannot be too "optimised"/smart because the userspace can already interract with the MPTCP socket at that point
- we can change the ULP ops
- to do something smart, the MPTCP socket should inherit from the TCP one: waste of memory, etc. just for the client side and to support fallbacks, probably not worth it.