> Instead of stopping path discovery when a path is found continue
> attempting to find paths until we hit the dot11MeshHWMPmaxPREQretries
> limit.
I am not too sure whether by simply broadcasting the PREQ frame could
actually solve the problem and this may cause problem of PREQ flooding
in your network when the number of nodes scale. Please take note that
all nodes need to rebroadcast the PREQ frame until target STA. Path
discovery should stop once the path is established. By attempting 2nd,
3rd or 4th doesn't guarantee the next path will be "good".
> This is important because path messages are not reliable and it is
> relatively common to have a short bad path to the destination along with a
> longer but better path. With the original code rather often a path message
> along the long path would be lost so we would stick with the bad path.
> With this change we have a greater chance to get messages over the longer
> path allowing us to select the long path if it's better.
Reduce the mesh_hwmp_active_path_timeout or mesh_path_refresh_time to
reestablish your path link as soon as possible. Also, if you would
like to have such aggressive behavior, you can reduce the
mesh_hwmp_preq_min_interval to have more aggressive PREQ sending in
your network.
----
Chun-Yeow
> > Instead of stopping path discovery when a path is found continue
> > attempting to find paths until we hit the dot11MeshHWMPmaxPREQretries
> > limit.
>
> I am not too sure whether by simply broadcasting the PREQ frame could
> actually solve the problem and this may cause problem of PREQ flooding in
> your network when the number of nodes scale. Please take note that all
> nodes need to rebroadcast the PREQ frame until target STA.
Yes, that is a real issue. We are planning on doing some further work in
this area to try to minimize the explosions that can be seen with PREQs in
larger networks while balancing the need for reliability.
Path discovery
> should stop once the path is established. By attempting 2nd, 3rd or 4th
> doesn't guarantee the next path will be "good".
It doesn't guarantee anything of course but it does raise the probability
that the right path will be found. For example take four nodes in a ring
where the A-B, B-C, C-D links are all good but the A-D link is poor. Poor
enough that the higher data rates are hosed for that link but the basic rate
used by management frames is relatively unaffected. If we assume that the
reliability of management frames is 90% then in order for A to route to D it
needs to get a PREQ to D and a PREP back. It has two options 1) for A-D the
reliability will be 0.9^2 = 81% 2) for A-B-C-D the reliability will be 0.9^6
= 53%.
This isn't a good situation because it makes it much too easy for routing to
pick a *really* bad path. And we have seen reliability improvements with
this patch.
We have already made changes to dial way back on the number of PREQs sent
out so this patch made quite a bit of sense for us. In the default
configuration where PREQs go out every 4s I don't think we have a good
solution: picking a bad path, even for 4s, can be a horrible user experience
but PREQ volumes quickly start consuming too much airtime as network sizes
increase.
-- Jesse