Future advanced networking improvements

[m-anish]

I'm creating this as a placeholder for possible future networking upgrades to the IIAB.

1. In large IIAB setups, QoS is increasingly an issue - one user watching a video eats up all the available wifi bandwidth. Something like radius can limit this problem. Another option can be packet filtering/shaping as described in the cookbook here -- http://lartc.org/howto/lartc.cookbook.ultimate-tc.html

2. There are many instances where upstream network connectivity is spotty (I don't need to give examples I think), there might be use cases where having more than one upstream connection can really improve conditions. Thankfully, multipath-tcp (http://multipath-tcp.org/) has been making some good strides on this front. To have a user experience that is transparent to the user and provides better and more reliable upstream connectivity, one would need to have multipath-tcp run on the IIAB (seems trivial to do on a recent debian/ubuntu machine), and have a multipath-tcp proxy hosted somewhere. The downside is that additional network bandwidth on the proxy/bridge end will be consumed -- but if some university/group is willing to support this, it can really improve things. We could additionally also choose for what kind of packets (data) to enable this for.

3. Multipath-tcp could potentially be useful on the LAN side as well, if there is IIAB and multiple routers involved. It could smartly route traffic between user-user and user-server. However, at this point, I am not very sure if it offers any tangible improvements over layer 2/3 meshing protocols such as batman-adv et. al.

[holta]

@m-anish hope it's Ok I'm moving this to IIAB 6.7 Milestone as our IIAB 6.6 final release is now approaching?

[m-anish]

Cool. I hope to start experimenting on this soon.

[jvonau]

Update: advanced options now in play
'second_gateway_found' function will exclude the associated interface from the available lan device string parsing by setting 'exclude_devices' which is also available to be used within local_vars.yml to tune excludes for a custom network layout.
'iiab_wired_lan_iface' is computed but available as an override in local_vars for use as slave under br0

Since I'm in a writing mood other options available but less known
'iiab_lan_enabled: False' disables creation of iiab manged dhcp network
'nobridge: True' turns off auto br0 creation.
'user_lan_iface: device' would trump and override iiab_lan_iface detection for iiab's dhcp clients.
'user_wan_iface' would trump and override iaib_wan_detection.

[tim-moody]

I take it these have precedence over everything else, for example

gui_desired_network_role == "LanController" is overruled by iiab_lan_enabled: False or nobridge: True

[jvonau]

I take it these have precedence over everything else, for example

gui_desired_network_role == "LanController" is overruled by iiab_lan_enabled: False or nobridge: True

'iiab_lan_enabled: False' is the big hammer to turn off all the "LAN" configuration, should effectively create an 'Appliance' like setup on the WAN side and ignore all other interfaces present.
'nobridge' implies just that, only one interface wired or wireless can be what would become the "LAN".