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.