Hi Adrian, I am encouraging those interested to wrote a draft indicating the observed issues and perhaps exploring the solution space. I assume that's what you would need to start having a meaningful discussion on reasonable options.
Thanks, Alia On Aug 10, 2015 5:41 AM, "Stephens, Adrian P" <adrian.p.steph...@intel.com> wrote: > 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 > > _______________________________________________ > 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
