On Tue, Mar 3, 2015 at 11:27 PM, Teco Boot <[email protected]> wrote: > >> 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
My best (well, worst) dataset here was in paris where in my 18th floor apartment I could "hear" over 200 APs, and was generally lucky to get a few dozen k in throughput from across the room. 5ghz was illegal at the time, it was all 2.4ghz traffic. As I recall, Mark Townsley also had trouble getting 2.4 ghz signal or bandwidth from across the room in his apt there, also. >> AP, the issue is keeping the density of AP from congesting airwaves. Yes. See the minstrel-blues work - which looks to make a dent in that problem by reducing signal strength whenever it makes sense. http://www.linuxplumbersconf.net/2014/ocw//system/presentations/2439/original/Minstrel-Blues%20@LinuxPlumbers%202014.pdf > With 5GHz, signal fades away rather quickly due to walls. False. It is mostly the low signal strength that is legal on the lower 5ghz bands that is the problem here. Higher bands usually let you have much more output power. But, that too creates problems. See above for one piece of a solution. I figure (since I am unsubscribed) this message will bounce. But whatever. > 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. h, also. > With 802.11ad, walls block RF. Thankfully, although I am waiting for products to appear and it appears this standard is mostly targetted at TV, not interactive applications. > >> >> 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. Um, no. Today's wifi stacks and most chipsets and drivers are horribly, horribly borken. >Next step is home wireless routers. This homenet WG should catch up. +10. > > Teco > >> >> Curtis >> >> _______________________________________________ >> homenet mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/homenet > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
