In message <CAGnRvuq+kq+djqPvKHDXBdDkbfjt=gnj0owqvc241vllwxb...@mail.gmail.com> Henning Rogge writes: > On Tue, Mar 3, 2015 at 8:12 PM, Curtis Villamizar <[email protected]> > wrote: > > The basis for the metric in RFC 7181 is out of scope. So what did you > > use? > > This: > https://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-04
It seems like with this draft, packet with RFC 5444 (Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format) sequence numbers are counted and absent any of those, only HELLO packets are counted. If all packets had RFC 5444 sequence numbers this would have the same effect as LQM. Unfortunately this requires the host to use RFC 5444 encapsulation over WiFi. Unfortunately LQM requires both side to play. On the bright side, a host would only need to copy counters into a packet to allow the AP to gather information. > I am still using the multicast loss (plus the raw link speed) to judge > the links, but I have done some early experiments with integrating the > L2 frame statistics too. Not sure it works that well for wifi without > a lot of probing, much more than you need for getting an useful link > speed). It would be nice to write down somewhere (preferably and internet-draft for WG purposes) exactly what you end up with once you've made good progress on this. > > Also I'm not sure what you meant by the "MPR code". Did you leave in > > the LINK_METRIC TLV and leave out the rest of RFC 7181? > > Multipoint Relays. Its a method to reduce the flooding overhead in a > wireless mesh network. Its defined in RFC 7181, but its a modification > of NHDP so I put it into my NHDP implementation. > > > So my point still stands that there is nothing like LQM is anything > > over WiFi (more correctly 802.11). > > With an Atheros card I get both transmitted frames, retransmitted > frames and (completely) lost frames on the sender side of a link... > its just that these values are not that useful when most of your > wireless links are not transporting traffic. > > Henning Rogge Its great that you are working on wireless mesh networks. IMHO the typical homenet environment is Ethernet plus WiFi in AP mode, not mesh. Its good to have things that work well for mesh. Right now it would be really good to have solutions for the problem of lots of AP in a confined area. In some cases, such as appartment buildings with lots of consumer run AP, the issue is keeping the density of AP from congesting airwaves. In other cases (such as IETF, or an enterprise with lots of APs) hosts will be roaming among APs and that should be smoother than it is now. Unfortunately I don't think that is fixable with zero host changes. Curtis _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
