> > 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%. > > What is round trip delay between A-D compared to A-B-C-D? 1 hop away the > throughput is reduced by half. Well A-D is going to have a much smaller RTT than A-B-C-D. And, yes, using multiple hops is going to reduce throughput but I'd much rather use multiple 120 Mbps links than a link that only supports 12 Mbps. >Also if you have more nodes using longer > path, you consume more airtime leads to really bad network performance, > especially when B, C, or even D wants to start initial data transmission. That's why there are link and path metrics. > One way of improving the path is either enhancing the airtime link metric > by > considering the factor that you mentioned in or else introducing vendor- > specific path metric. Sending more broadcast frames over the network won't > be a good solution. Improving the link metric isn't going to help with PREQ reliability problems. Sending more PREQs will. -- Jesse
