Hi, Bob > Having not been around at the introduction of net_traversal_jiffies > (and it goes back to mesh landing in mainline), I can't really say. > This looks more like a bug to me than intended behavior though. > > We're not fully eliminating net_traversal_jiffies(): we still only > update the SN only once per 50 ms (configurable) period. But, before, > we would send PREPs that would in practice never be used due to using > old target_sn, so only one last-hop path per 50ms would be considered > (unless the PREP got dropped or something). > > With the change, we're still sending the same number of PREPs but now > more are usable. Multiple last hop paths can be considered, so it's > no longer rand(). It could be the case that we will get more > path changes as a result (try bad path because of new SN, try better > path because of same SN and better metric, ...), but path quality should > be better. > > If net_traversal_jiffies() were completely eliminated (and I guess > one could do that by configuring it to 0), then I think we would see > more short-term fluctuations when path metrics are equal at the last > hop. > > I guess I'll go try and find the draft language mentioned by the paper > to see what it says. >
I just take a look on the IEEE Std 802.11-2013 and dot11MeshHWMPnetDiameterTraversalTime is discussed in section 13.10.8.6. If I understand correctly, it seems that dot11MeshHWMPnetDiameterTraversalTime is only applicable to originator HWMP SN, right? On the target HWMP SN, it is discussed in section 13.10.8.3 as follow: "If it is a target mesh STA, it shall update its own HWMP SN to maximum (current HWMP SN, target HWMP SN in the PREQ) + 1 immediately before it generates a PREP in response to a PREQ." Is this mean that we should ignore net_traversal_jiffies in target HWMP SN? This seems that we always construct the same forward path and reverse path. If we use the same target HWMP SN in PREP, there is possible of different forward path and reverse path been used. >> Also, as mentioned in [1], should we also consider the subsequent >> PREQs with same metric instead of just only better metric in our >> current implementation? > > I considered this and even wrote a patch for it... but wouldn't this > just cause a last-in wins scenario? It looks like we already include > the metric to the sender when considering the PREQ/PREP frame in > hwmp_route_info_get(), so if we did have an equal metric, and passed > on the frame, there's no way for subsequent nodes to disambiguate the > cases, no? Agreed. Make no sense of just considering last-in wins scenario. ---- Chun-Yeow _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
