On Mon, Feb 10, 2014 at 11:44:23AM +0800, Chun-Yeow Yeoh wrote: > Hi, Bob > > net_traversal_jiffies as claimed in [1] is used to improve patch > stability in short term. This patch is more or less like eliminating > the purpose of net_traversal_jiffies, right?
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. > 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? > [1] Rosario G. Garroppo, et al. , "A joint experimental and simulation > study of the IEEE 802.11s HWMP protocol and airtime link metric" -- Bob Copeland %% www.bobcopeland.com _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
