Hello Mikael > 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.
Many products do that. But then people immediately think about sending unicast only to those who need the packet. Good idea isn't it? The basic APs will apply rules like 'oh, we do not expect a router on Wi-Fi so let's drop all RS towards wireless'. Hardcoded in the box. Clearly, a behavior like this that is not backed by a standard, appears to be working, well, until it is no more, and at worse people may 'learn' that they cannot have routers over Wi-Fi. Damn. More advanced and expensive devices will learn addresses from snooping various protocols and devising their own way of figuring which address (unicast, multicast) which STA is listening to. But a DAD may easily be missed and a state may not be created when it should have. A protocol may be misinterpreted, some bug, some new version of the protocol. A state may be kept for too long and may cause denial of service. Because none of that is standard, different special sauces from different vendors will cause interoperation issues. Think about the impact of firewalls that we have suffered over the years, applied to the network operation down to the basic protocols. Vendor-specific magic heuristics about how to play with snooped state that are deployed today will have unpredictable effects on new protocols in the future that expect standard behavior from deployed boxes. Add to that new host behaviors like rapid renewal of IP addresses for privacy reasons and you see that the good idea above was the recipe to first shoot oneself in the foot and then all the way up. > > >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). Such a thing is just untrue. IP works on any link, it has to. That's why we do IP over Foo. Now all we need is IP over Wi-Foo for radios such as .11. As for protocols that rely on IP multicast, it's IP's problem. If the underlying link layer does not have multicast, it is IP's responsibility to emulate it. > > 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". > That is not my conception of IP. That would be Inter-Some-Net protocol now. > 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. Not All protocols, just IP basic things like ND, and then use IP multicast routing even in a ML subnet. For ND, it is already done for 802.15.4, RFC 6775, will need some additional stuff to make it generic Wi-Foo. > 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. This also has already started with the efficient ND work at 6MAN and many drafts from design team members. Cheers, Pascal > > 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? > > 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
