On Fri, Jun 26, 2015 at 01:05:06PM -0700, Jesse Jones wrote: > > > My big worry is that we will select bad paths. And this *will* happen. > > > I've seen it many times. And if it does happen the effects are not > > > theoretical; they are by definition bad. We *have* selected a bad path > > > after all. And when we select a bad path it will be very apparent to > > > end users. Bandwidth will be lower than it should be and loss may go up > > > as > > well. > > > > Agreed with your point. How about adding nl80211 command for this? > > I'm not keen on the idea. I still think it's the right thing to do and I > don't much like the idea of having to turn it on. And it will become an even > better idea if we don't refresh as often (eventually I'll send a patch for > that though I think I may have to massage what we're using now). At the very least I think this is a change in semantics around dot11MeshHWMPmaxPREQretries -- the intent as far as I know is to limit total attempts to determine whether target is reachable at all, and I don't think there is enough evidence in the standard to support the other interpretation. In my opinion it's also somewhat confusing that a 'max' parameter is used as a 'min'. I could also see some users wanting different behavior here depending on node density. So, at the risk of having too many knobs, could we perhaps add another tunable for this, call it min_preq_attempts or something, and fix it to the interval [1, dot11MeshHWMPmaxPREQretries]? My preference would be to maintain the default value of 1. -- Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
