I am delighted to see a cross layer conversation on wifi finally taking place here. I gave a talk at last weeks battlemesh about a few of the things in the pipeline to improve it:
https://plus.google.com/u/0/107942175615993706558/posts/W5tynWhK8v1 The fun part, where I lay out one of the big reasons why aggregation does not work as well as it could - using the folk in the room to emulate packets and queue behavior - starts at about 27 minutes in. I do not have sufficient time or finances (I am in the eu that month) to make it to the sept 13 802.11 meeting in thailand, but I would certainly like it if more concerned homenet wg participants and others that care about the future of wifi could attend an 802.11 wg meeting once in a while. On Mon, Aug 10, 2015 at 2:15 AM, Toerless Eckert <eck...@cisco.com> wrote: > > This is a nice start for what i'd call poblem 2): making > multipoint delivery of serious amount of data to more receivers more > reliable. Would love to understand if there is any definition of how > this would or could be used for actual IP multicast, eg: where > is the definition of using IGMP membership reports to > track receivers, automatically define a GCR etc. pp ?? I'd be surprised > if 802.11 would elevate to that level... Maybe thats something we > could/should do ? > > But yes, this is not solution to problem 1) which is about IP signaling > protocols that currently rely on multicast. We should target something > that has a lower set of requirements against APs (like worst possible AP > needs to work for us), and we probably want to take more care of > battery. (I say probably because i still haven't seen good simple but > persuasive > numbers for wifi-multicast vs. real world batery drain, so i am operation on a > faith base only here which i don't particularily like. ) > > On Mon, Aug 10, 2015 at 10:42:40AM +0200, Henning Rogge wrote: >> On Mon, Aug 10, 2015 at 10:34 AM, Mikael Abrahamsson <swm...@swm.pp.se> >> wrote: >> > Donald Eastlake posted this a few days ago: >> > >> > "- 802.11 does have a feature called GCR -- Groupcast With Retries, >> > which was part of the 802.11aa amendment, although it is not widely >> > implemented. It includes such features as a way for the AP to send >> > several multi-destination frames and then, using unicast, to poll >> > associated stations for a bit map of which of those frames they >> > correctly received (BlockAck) and a feature for the AP to >> > spontaneously transmit a multi-destination frame more than once >> > without causing confusion for improved reliability." >> >> Okay... >> >> this is quite new and I am not sure it will solve all the multicast >> problems for 802.11. Neighbor discovery (both IPv6 and routing >> protocol) has potentially to deal with a lot of neighbors, some of >> them not even known to the transmitter. It also feels like a lot of >> consumed airtime to replace a multicast with a multicast and one >> unicast for each known neighbor. This could be dozens of media >> accesses. >> >> Henning Rogge > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
