Hi Dan, Thanks for forwarding this.
a) I agree with Donald's comments below. b) 802.11 also defines a Proxy Neighbor Discovery capability, and the mechanism for an AP to advertise that it provides this service. This is starting to be implemented (part of Wi-Fi Alliance Passpoint certification) but is not widely deployed. c) 802.11 defines a Directed Multicast service (multicast to unicast conversion). This is not widely implemented. d) Additionally, most if not all AP vendors implement multicast - unicast conversion and use it as they see the need for it. e) This topic seems in need of a richer dialogue, possible steps include: - develop a presentation describing the problem(s). http://www.ipv6council.be/IMG/pdf/20141212-08_vyncke_-_ipv6_multicast_issues-pptx.pdf is a start. - present in 802.11. The next 802.11 meeting is September 13-18 in Bangkok. Alternatively, we can set up a teleconference with 10 day notice. Dorothy -----Original Message----- From: Donald Eastlake [mailto:d3e...@gmail.com] Sent: Thursday, August 06, 2015 7:01 AM To: Romascanu, Dan (Dan) Cc: Mikael Abrahamsson; Glenn Parsons; Toerless Eckert (eckert); Dorothy Stanley; ieee-ietf-co...@ietf.org; Homenet; Alia Atlas; Acee Lindem (acee); Eric Gray Subject: Re: [ieee-ietf-coord] [homenet] Despair 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
