> Updating the path to the transmitter of a path message is optional
> according to section 13.10.8.4 of the standard. Doing so can lead to
> better performance since we can adjust the route to the transmitter based
> on the freshest possible information. However it can also cause routing
> loops with more than four or five nodes.
Do you have the test scenario on how routing loops happen in this case?
Thanks
----
Chun-Yeow
Sorry I miss out your previous email.
> We did this over a year ago and I don't think we saw routing loops though
> iirc we saw better performance when we made the change. Most likely because
> of the other problem with the original code: it creates a path to the ta if
> none exists but does not go through discovery to do so.
Yes, it is a direct hop towards the mgmt->sa,
> So if the direct hop
> is not the best path you're going to be stuck with a crappy path until the
> next refresh.
But hey, the code has already compared the path metric, right? Next
refresh, so if you reduce the active path timeout
(dot11MeshHWMPactivePathTimeout), you solve the problem, right?
> In any case updating metrics without doing an SN feasibility check is highly
> suspect.
As cited in section 13.10.8.4, "the mesh STA may create or update its
forwarding information to the transmitter of the element if the path
metric improves." So it is correctly implemented.
> I'm not 100% sure this instance will cause routing loops but I do
> know that every time I have tried to be clever and optimize routing without
> looking at both the SN and metric I have wound up with routing loops.
I would recommend to add nl80211 command to disable this. After all,
it may change other people's network behavior.
Also, you may post you patch to o11s mailing list and your test
scenario. Maybe others can verify as well to be 100% sure.
Thanks
---
Chun-Yeow
> > There are two test scenarios:
> > 1) When creating the path to a ta where the direct hop is a bad path.
> > Relatively easy to setup and demonstrate poor performance pre-patch.
> > 2) Incorrect routing when the metric for an existing SN is changed
> > without also updating the SN. Hard to demonstrate. We've certainly
> > seen similar bugs with our own mesh protocols but that was with
> > protocols explicitly designed with testing support. Best approach is
> > probably via something like http://alloy.mit.edu/alloy/
>
> If the direct hop is a bad path, could it be due the metric calculation.
Sure, metric calculations are not perfect. But that is an entirely separate
can of worms. For the purposes of this discussion we can assume that the
metrics are perfect. Simplest case is the one I mentioned before: a U where
we're trying to route between the ends of the U but the direct hop is bad
and the links along the U are excellent.
> Also, you may also add your vendor specific mesh protocol to open source
> community.
Maybe. We spent many man years on it and eventually got it routing well. It
was all done in a commercial setting though so I don't know that we would
open source it.
-- Jesse
> Sorry I miss out your previous email.
>
> > We did this over a year ago and I don't think we saw routing loops
> > though iirc we saw better performance when we made the change. Most
> > likely because of the other problem with the original code: it creates
> > a path to the ta if none exists but does not go through discovery to do
> > so.
>
> Yes, it is a direct hop towards the mgmt->sa,
>
> > So if the direct hop
> > is not the best path you're going to be stuck with a crappy path until
> > the next refresh.
>
> But hey, the code has already compared the path metric, right? Next
> refresh,
> so if you reduce the active path timeout
> (dot11MeshHWMPactivePathTimeout), you solve the problem, right?
Most likely. But selecting a bad path for 30s (or whatever
dot11MeshHWMPactivePathTimeout is set to) is not a good idea. Of course
usually the direct hop will be the best path but that is certainly not
guaranteed.
> > In any case updating metrics without doing an SN feasibility check is
> > highly suspect.
>
> As cited in section 13.10.8.4, "the mesh STA may create or update its
> forwarding information to the transmitter of the element if the path
> metric
> improves." So it is correctly implemented.
Yes, my argument is that that was a bad idea on the part of the standard and
optional so we can remove it.
> > I'm not 100% sure this instance will cause routing loops but I do know
> > that every time I have tried to be clever and optimize routing without
> > looking at both the SN and metric I have wound up with routing loops.
>
> I would recommend to add nl80211 command to disable this. After all, it
> may
> change other people's network behavior.
>
> Also, you may post you patch to o11s mailing list and your test scenario.
> Maybe others can verify as well to be 100% sure.
There are two test scenarios:
1) When creating the path to a ta where the direct hop is a bad path.
Relatively easy to setup and demonstrate poor performance pre-patch.
2) Incorrect routing when the metric for an existing SN is changed without
also updating the SN. Hard to demonstrate. We've certainly seen similar bugs
with our own mesh protocols but that was with protocols explicitly designed
with testing support. Best approach is probably via something like
http://alloy.mit.edu/alloy/
-- Jesse
On Thu, Jun 25, 2015 at 9:55 AM, Yeoh Chun-Yeow <[email protected]> wrote:
>> Updating the path to the transmitter of a path message is optional
>> according to section 13.10.8.4 of the standard. Doing so can lead to
>> better performance since we can adjust the route to the transmitter based
>> on the freshest possible information. However it can also cause routing
>> loops with more than four or five nodes.
>
> Do you have the test scenario on how routing loops happen in this case?
>
Sorry, I don't see the "optional" work in section 13.10.8.4. Please
note that this maybe useful for most of the cases.
I would recommend to add nl80211 command for doing so. So, others
still can enjoy freshest possible information. What do you think?
----
Chun-Yeow
> > Updating the path to the transmitter of a path message is optional
> > according to section 13.10.8.4 of the standard. Doing so can lead to
> > better performance since we can adjust the route to the transmitter
> > based on the freshest possible information. However it can also cause
> > routing loops with more than four or five nodes.
>
> Do you have the test scenario on how routing loops happen in this case?
>
> Thanks
>
> ----
> Chun-Yeow
We did this over a year ago and I don't think we saw routing loops though
iirc we saw better performance when we made the change. Most likely because
of the other problem with the original code: it creates a path to the ta if
none exists but does not go through discovery to do so. So if the direct hop
is not the best path you're going to be stuck with a crappy path until the
next refresh.
In any case updating metrics without doing an SN feasibility check is highly
suspect. I'm not 100% sure this instance will cause routing loops but I do
know that every time I have tried to be clever and optimize routing without
looking at both the SN and metric I have wound up with routing loops.
-- Jesse
> There are two test scenarios:
> 1) When creating the path to a ta where the direct hop is a bad path.
> Relatively easy to setup and demonstrate poor performance pre-patch.
> 2) Incorrect routing when the metric for an existing SN is changed without
> also updating the SN. Hard to demonstrate. We've certainly seen similar bugs
> with our own mesh protocols but that was with protocols explicitly designed
> with testing support. Best approach is probably via something like
> http://alloy.mit.edu/alloy/
If the direct hop is a bad path, could it be due the metric calculation.
Also, you may also add your vendor specific mesh protocol to open
source community.
---
Chun-Yeow