Hello all, Let me summarise some of the characteristics of the 802.11 standard related to multicast: 1. The basic "packet error rate" (before Ack) designed to is 10% in the case of unicast. This is a very broad statement and almost so simplistic as to be misleading. Errors are composed of 1) collisions, 2) interference, 3) rate/MCS adaptation errors, 4) sudden changes in the radio environment such as shadowing. The residual error for unicast is less because of the retry mechanism.
2. Multicast is generally sent at a low "basic" (one intended to be receivable by all STAs in the AP's network) rate. This improves reliability in some of the error causes cited above, but not all. 3. Multicast is generally not acknowledged. 4. Multicast may be buffered when power-savers are present. An AP may discard buffered traffic due to internal resource constraints. Buffered multicast traffic is generally delivered once per DTIM, which is a configurable multiple of the beacon interval. Note that the asymmetry of the buffering times might cause an AP to discard more buffered multicast traffic than unicast. Whether it does is something I don't know, I'm just mentioning it as a possibility. 5. When multicast is delivered using the DTIM mechanism, a whole sequence of buffered multicast frames are transmitted using a "SIFS" gap (i.e. uninterruptable). This reduces the probability of individual packet collision from nearby STAs. 6. The STAs associated with an AP may exhibit different reliabilities receiving multicast traffic. Those on the edge of the AP's network will receive at lower power. More subtly, they may be closer to 802.11 interferers that cannot receive from the AP, and therefore do not honour any of the protection mechanisms that might be used by the AP. The bottom line of operating in an unlicensed medium is that nothing is predictable and there are absolutely no guarantees. The standard contains mechanisms to improve the reliability of multicast and remove it from the DTIM buffering mechanism. Implementations can do a multicast to unicast translation. The standard does not support this, but it does not prevent it either. The question in my mind is whether this discussion thread is uncovering any new requirements for the 802.11 standard. I can make time on the 802.11 meeting agenda to discuss the topic. Dorothy Stanley is 802.11's liaison to IETF, so if folks did want to contribute to a discussion document, I suggest they work with her. Our next meeting is September 13-18. (http://www.ieee802.org/11/Meetings/Meeting_Plan.html) Yours sincerely, Adrian P STEPHENS Chair, IEEE 802.11 Working Group Tel: +44 (1793) 404825 (office) ---------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 -----Original Message----- From: ieee-ietf-coord [mailto:ieee-ietf-coord-boun...@ietf.org] On Behalf Of Pat (Patricia) Thaler Sent: 08 August 2015 01:08 To: Mikael Abrahamsson; Pascal Thubert (pthubert) Cc: Toerless Eckert (eckert); ieee-ietf-co...@ietf.org; Dan Romascanu (droma...@avaya.com); Glenn Parsons; Homenet; Alia Atlas; Acee Lindem (acee); Eric Gray Subject: Re: [ieee-ietf-coord] [homenet] Despair No one is saying that 802.11 can't do multicast. It does do multicast, but with more loss than the protocols sending multicast may assume or be able to accommodate. As I understand the presentation that kicked off this discussion, this becomes an issue since IPv6 relies more on multicast. While IP came first, IPv6 didn't. Increasing use of low power devices that have times when they "sleep" and therefore miss multicasts contributes to the problem. But low power use for battery or low-energy source based devices is essential. It isn't going away. (Wired devices sleep to save energy too but they are generally less power constrained so they are able to go into a less deep sleep and can wake to receive traffic.) And even when wireless devices don't sleep, they experience varying connectivity due to movement. Pointing fingers isn't going to help this. We need to get together and see what can be done to improve the situation. Regards, Pat -----Original Message----- From: ieee-ietf-coord [mailto:ieee-ietf-coord-boun...@ietf.org] On Behalf Of Mikael Abrahamsson Sent: Thursday, August 06, 2015 11:22 PM To: Pascal Thubert (pthubert) Cc: Toerless Eckert (eckert); Alia Atlas; Dan Romascanu (droma...@avaya.com); Glenn Parsons; Homenet; ieee-ietf-co...@ietf.org; Acee Lindem (acee); Eric Gray Subject: Re: [ieee-ietf-coord] [homenet] Despair On Thu, 6 Aug 2015, Pascal Thubert (pthubert) wrote: > It is simply unfair from the IETF to use Wi-Fi as if it was Ethernet > and then complain to IEEE that in fact it is not. This is an interesting viewpoint. IETF isn't "using wifi as if it was Ethernet". The customers who buy Wifi products buy it and run IP over it, expecting it should work (because that's what the advertising says). IP has been designed for wired ethernet (and Wifi carries ethernet frames). As far as I can tell, 802.11 never told the IETF that it wouldn't support multicast (really). I'd say IETF isn't saying "IP works great over Wifi" (it doesn't really make any claims for any L1 or L2). However, I see producers of Wifi equipment saying that their products are great for using to connect to the Internet, which is saying "Wifi is great for IP". > IPv6 over Ethernet makes heavy use of multicast over Ethernet, which > for the lack of a highly scalable Multicast service always ends up > broadcasted over the whole fabric. > > When Wi-Fi is confused with Ethernet and the whole multi link becomes > a single layer 2 fabric, we create a crisis that will not be solved by > imputing the responsibility on the other SDO. Which is exactly why I said that both SDOs need to do something. However, since IP was "first" I think that 802.11 should have come to IETF a long time ago and said that it couldn't do multicast. Basically, what I interpret you're saying is that Wifi in its current form isn't suited to carry IP the way IP has been designed, for a long time. That would be news for a lot of people. > My suggestion is to finally recognize that Wi-Fi is not Ethernet, in > particular from the perspective of multicast, and provide the > appropriate L3 mechanisms for IPv6 over Wi-Fi, for which the backbone > router discussed above is one candidate solution. It's not only IPv6, but it's also IPv4 (since it uses broadcast, but less of it). But what I hear here is that your opinion is that 802.11 doesn't need to change, but the IETF needs to change for IP to work over Wifi. I'd really appreciate some kind of official agreement from each SDOs who should do what. If the long-term technical solution is that the IETF should change L3 to basically avoid broadcast and multicast, then that's fine, as long as this is agreed upon by both parties. However, I do think that 802.11 needs to point out to its members that if they don't implement assured multicast replication, IP doesn't work properly. Then they can decide what should be done in the short term, because changing IP will take quite a while. -- 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 _______________________________________________ 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
