> Op 3 mrt. 2015, om 21:50 heeft Curtis Villamizar <[email protected]> het > volgende geschreven: > > 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.
With 5GHz, signal fades away rather quickly due to walls. This has as a disadvantage that even in moderate sized homes, there are multiple 5GHz APs needed for good performance (>20Mbps). So the number of WiFi AP's in homes will grow and there's a need for support of IEEE 802.11k and 802.11r. With 802.11ad, walls block RF. > > 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. In today's WiFi stack and good WLAN controller, this works quite well. Next step is home wireless routers. This homenet WG should catch up. Teco > > Curtis > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
