Feature Request: use 802.11s features for better control of meshlinks

[A-Kasper]

For better performance it could be nice to have control about some Mesh-Links
802.11s features some options we could use to get control about the mesh-links of a node.

For example we could provide white- or blacklisting of nodes the node is meshing with:
https://github.com/o11s/open80211s/wiki/HOWTO#advanced-tinkering

other possible 802.11s parameters are:
Possible mesh parameters are:

• mesh_retry_timeout
• mesh_confirm_timeout
• mesh_holding_timeout
• mesh_max_peer_links
• mesh_max_retries
• mesh_ttl
• mesh_element_ttl
• mesh_auto_open_plinks
• mesh_hwmp_max_preq_retries
• mesh_path_refresh_time
• mesh_min_discovery_timeout
• mesh_hwmp_active_path_timeout
• mesh_hwmp_preq_min_interval
• mesh_hwmp_net_diameter_traversal_time
• mesh_hwmp_rootmode
• mesh_hwmp_rann_interval
• mesh_gate_announcements
• mesh_fwding
• mesh_sync_offset_max_neighor
• mesh_rssi_threshold
• mesh_hwmp_active_path_to_root_timeout
• mesh_hwmp_root_interval
• mesh_hwmp_confirmation_interval
• mesh_power_mode
• mesh_awake_window
• mesh_plink_timeout

It would also be nice if iw dev mesh0 station dump parameters like the bitrates and expected throughput could be shown at the statuspage. (btw: I think the beacon interval of 100 could be longer. )

[neocturne]

I think most 11s options aren't very interesting for us, as we do all the routing decisions in a higher-layer routing protocol and only use 11s as a replacement for adhoc mode.

Some work on allowing to blacklist links was done in freifunk-gluon/packages#118, but it is not finished.

Increasing the beacon interval is probably a good idea, we just need to decide on a good value (also, all VIFs use the same beacon interval, so changes will affect the AP interfaces as well).

[CodeFetch]

Increasing the beacon interval will not solve the problem that a frequency is crowded. Don't expect much bandwidth increase from that (maximum 10%). What you really want is TDMA or at least RTS/CTS in case of overlapping BSSes. For example http://netshe.ru/ has build a batadv14-based TDMA implementation which doesn't use packet loss but nl80211 wifi information for metric calculations (but it is closed source and not maintained well enough).
ATH9K HMAC https://github.com/szehl/ath9k-hmac is a proof-of-concept implementation of using a little hack to make TDMA work without breaking CSMA/CA. With this one could make sure that the AP networks don't interfere with the Mesh networks, but it would need someone like NeoRaider to get this clean for upstream kernel support. The userspace netlink communication interface is written in C++ and needs to be rewritten in C first. There is also no handler for dynamic setting of TDMA rules.

[CodeFetch]

Maybe I've found a problem that makes 802.11s performance worse.
802.11s has a feature called MCCA which is a collision avoidance mechanism working similar to TDMA. All 802.11s neighbours are synchronised (see 802.11s Mesh Synchronization) by default. This is astonishingly accurate (average <10 microseconds). Unlike TDMA MCCA does not use timeslots but DTIM intervals. A 802.11s node can request via unicast or multicast such a DTIM interval for it's use. All neighbouring nodes will either deny or accept this via a reply depending on any overlap with their own intervals. Thus MCCA is some kind of self-organising TDMA feature for 802.11s which is really cool and I wish I knew about it before.

As far as I can see the DTIM-intervals of the mesh interface have no effect on the other VIFs. If that's true then I consider 802.11s with multiple VIFs as a little broken.
Similar to how ath9k-hmac uses the powersafe mode to stop the transmit queues of ath9k an 802.11s VIF needs to be able to stop other VIFs from transmitting outside of its own DTIM interval.

Edit: I think this is not the big issue as it seems that MCCA isn't implemented in ath9k at all. Could EDCA have any problems with multiple VIFs (does it utilise queue scheduling)? What about broadcom/ralink drivers? I think one could check the IEs if the code is closed source or simply too confusing. Unfortunately I don't know the correct format for that and found only this:

Each station can
enable its support for MCCA and show this support by setting to 1 the MCCA Enabled bit,
which is in the Mesh Capability Subfield of the Mesh Configuration Element present in
beacons and probe responses. Another station may support MCCA but not implement it (the
Mesh Capability subfield also includes a MCCA Supported bit). In that case, the station can
participate in the MCCA mechanism, but cannot initiate any MCCA reservation.
see https://www.cwnp.com/uploads/802-11s_mesh_networking_v1-0.pdf

[neocturne]

Closing: Most 11s options aren't relevant for Gluon. If we find a specific option interesting to support, a separate issue should be opened.

See also:

• Setting plink_action for 802.11s neighbours #421 (blocking individual mesh links)
• gluon-core: add support for configuring the beacon interval #2028 (beacon interval configuration)