I think there are some problems with slide 5 of the references presentation. Although I am active in IEEE 802.11 this is not particularly my area of expertise. I'm sure Dorothy will correct me if I'm wrong:
- The claim that the AP must retransmit multi-destination frames as the "lowest possible" rate seems a bit misleading. Beacons (AP originated station discovery frames) should be sent at the lowest rate the AP is configured to use and Probes (station originated AP discovery frames) should be sent with the lowest rate the station is configured to use. Multi-destination data need only be sent at the lowest rate needed for the worst of the associated stations, although an AP could send slower if it wanted to, which still uses less air time than serially unicasting since you would have to send it at that slow rate anyway to that worst station. In any case, none of these is the "lowest possible" rate, which I assume means the slowest/most-robust modulation defined in the 802.11 standard. - 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. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Thu, Aug 6, 2015 at 3:47 AM, Romascanu, Dan (Dan) <droma...@avaya.com> wrote: > Hi Mikael, > > I agree that we need a more focused dialog. I am copying to your message the > IEEE 802 - IETF coordination list. FYI - this is a team of IETF and IEEE 802 > experts that includes but is not limited to the ADs who work on issues that > require coordination between the IETF and the IEEE on the lines described by > RFC 7241. Folks who are interested to join this activity - please write to > me. You should also know Dorothy Stanley who is the liaison manager of IEEE > 802.11 to the IETF. Let us see what other participants in IEEE 802 have to > say about this before we discuss how we can best proceed. > > Regards, > > Dan > > > >> -----Original Message----- >> From: Mikael Abrahamsson [mailto:swm...@swm.pp.se] >> Sent: Thursday, August 06, 2015 9:45 AM >> To: Glenn Parsons >> Cc: Alia Atlas; Acee Lindem (acee); Toerless Eckert (eckert); Homenet; Eric >> Gray; Romascanu, Dan (Dan) >> Subject: RE: [homenet] Despair >> >> On Thu, 6 Aug 2015, Glenn Parsons wrote: >> >> > As I indicated in another thread, the right place to start a discussion on >> > this >> would be in the IETF-IEEE 802 coordination that Dan leads. >> > >> > While this issue may be solved be current work underway (and included in >> the coordination), perhaps a clearer problem statement would help us to >> ensure that is the case. >> >> There are documents that talk about multicast from a power efficiency >> standpoint: >> >> https://tools.ietf.org/html/draft-ietf-6man-rs-refresh-00 >> >> Slide 2 of >> http://www.ipv6council.be/IMG/pdf/20141212-08_vyncke_-_ipv6_multicast_issues-pptx.pdf >> pretty much sums it up, most of IETF protocols are designed around multicast >> being as reliable as unicast. IPv6 relies on this. On 802.11 this isn't the >> case. >> Slide 5 describes how this works in 802.11. >> >> The fact that multicast and broadcast is unreliable (not ACKed) on 802.11 is >> from what I can see the major cause of the unreliability problem that the >> mesh wifi networking protocols are trying to solve by basically only using >> multicast for discovery. >> >> The whole question is whether this should be fixed by 802.11 or if the IETF >> needs to (basically) abandon multicast/unicast, or if the IETF should develop >> a multicast->unicast replication mechanism for wifi (there is work in this >> area >> going on). >> >> Personally, I think 802.11 needs to fix multicast/unicast so it's reliable, >> or get >> back the IETF and say it can't be fixed and then the IETF can continue the >> work on multicast reduction (or workaround) even harder. >> >> I find the current approach of (basically) individuals within the IETF >> working >> on multicast reduction without (as far as I can see) any dialogue with 802.11 >> to be a non-optimal way of solving the problems we're seeing. >> >> -- >> Mikael Abrahamsson email: swm...@swm.pp.se > > _______________________________________________ > ieee-ietf-coord mailing list > ieee-ietf-co...@ietf.org > https://www.ietf.org/mailman/listinfo/ieee-ietf-coord _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
