Hello Mikael, Please see my responses embedded below...
Best Regards, Adrian P STEPHENS Tel: +44 (1793) 404825 (office) Tel: +1 (971) 330 6025 (mobile) ---------------------------------------------- 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 Mikael Abrahamsson Sent: 10 August 2015 10:27 To: Stephens, Adrian P Cc: ieee-ietf-co...@ietf.org; Dan Romascanu (droma...@avaya.com); Glenn Parsons; mbo...@ietf.org; Homenet; Eric Gray Subject: [ieee-ietf-coord] Multicast on 802.11 (included mbo...@ietf.org and also changed subject to something more appropriate) As far as I can tell, so far people have told IETF it's their job to reduce multicast to make IP based protocol "work" on 802.11 media. That's at least what I have been seeing. Considering the reactions from other parties, it seems the "multicast sucks on 802.11" is something 802.11 hasn't heard of before. [Adrian P Stephens] This problem is nothing new. We know about the relative performance of multicast vs unicast. Saying it "sucks" is not very helpful. Unlicensed spectrum is free. You are getting more than you are paying for :0). The only thing IETF can do is to use less multicast, and the obvious way of solving it is to just replicate into unicast. This seems like a suboptimal way to work around the problem if there are a lot of nodes. [Adrian P Stephens] The technical solution is surely to add a class of service specification to multicast packs that indicates their sensitivity to loss. The point is that the AP is in possession of a lot of data about individual nodes that may help it make an informed decision between unicast and multicast. Moving the duplication into the IP layer ensures uninformed decisions. >From what I read below, one way out of this is the IETF making a clear statement that multicast is an integral part of IP networking, and if a medium doesn't support delivering multicast frames in a similarily reliable fashion to unicast, it's not suited to carrying IP based protocols (or any other protocol that uses L2 broadcast/multicast). [Adrian P Stephens] <irony type="british; very-subtle"> I'm guessing you will be the first to turn off the 802.11 networking on your devices when the IETF makes such a statement. </irony> It seems to me that there are a few paths that the IETF could go: Write an RFC stating requirements on L1/L2 protocols when it comes to unicast, multicast and broadcast handling of packets. This could include options for mechanisms that turned multicast/broadcast into unicast that certain medias could have as requirements. Then IEEE could create a device profile that would fulfil these requirements, possibly add a certification, and then try to get market pressure to require devices to support this profile. The IETF wouldn't change its mind about how multicast is used in its protocols after this, but just say "this is the reality, please deal with it when you create L1/L2 that's supposed to carry IP". Or the IETF could just say that this seems like a lost cause, multicast/broadcast doesn't seem to work on some L1/L2, and start working on techniques that minimizes broadcast/multicast and change all the protocols to reflect this new reality. Something in the middle, but anyway changing the requirements on IETF protocols to avoid using multicast if it can, documenting where it makes sense and when it doesn't. Right now what I am seeing is that there are people who are lobbying to do away with multicast as much as possible because they see that in reality it's not reliable on the devices they have tested it on. What are the odds that 802.11 could agree on a device profile for "IP use" that would include reliable multicast delivery, and one that there is reasonable belief that this would gain significant market adoption? [Adrian P Stephens] As I indicated in my earlier post, there are multiple actors here. The odds are pretty good that 802.11 will respond to a clear requirement to handle multicast specially. If has, after all, already done this twice. What are the odds that the WFA will create a new certification? What are the odds that it is successful in the market? These are presently unknowns, and will remain that way until tried. On Mon, 10 Aug 2015, Stephens, Adrian P wrote: > Hello Mikael, > > " For me, it seems these 802.11 broadcast/multicast ACK functions should be > "mandatory" to implement if the device wants to support IPv4 and IPv6 > networks. > > How do we achieve this?" > > There are two routes to "mandatory". The standard can indicate something is > mandatory if you support > a particular feature. > > The second is certification. This is the not-so-simple task of persuading a > sufficient number of WiFi-Alliance members > that it is in their economic interest to support the feature that a > certification program can be created. Even, given a > certification, the market will still decide whether that is relevant or not. > > > Best Regards, > > Adrian P STEPHENS > > Tel: +44 (1793) 404825 (office) > Tel: +1 (971) 330 6025 (mobile) > > ---------------------------------------------- > 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 Mikael Abrahamsson > Sent: 10 August 2015 08:32 > To: Stephens, Adrian P > Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler; > ieee-ietf-co...@ietf.org; Dan Romascanu (droma...@avaya.com); Glenn > Parsons; Homenet; Eric Gray > Subject: Re: [ieee-ietf-coord] [homenet] Despair > > On Mon, 10 Aug 2015, Stephens, Adrian P wrote: > >> The question in my mind is whether this discussion thread is uncovering any >> new requirements for the 802.11 standard. > > Thanks for the summary, it seems correct. > > It might not need new 802.11 standards, but we still have an operational > problem in that it seems some of these standards are not universally > implemented by 802.11 based device vendors. > > IETF standards generally assume that multicast and unicast are delivered with > a similar level of packetloss (which is low). > > Not all 802.11 implementations have the multicast ACK mechanism implemented, > thus it would seem that multicast will be less likely to get delivered to the > recipient over these 802.11 implementations. > > For me, it seems these 802.11 broadcast/multicast ACK functions should be > "mandatory" to implement if the device wants to support IPv4 and IPv6 > networks. > > How do we achieve this? > > -- > 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 > -- Mikael Abrahamsson email: swm...@swm.pp.se _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
