RE: On the "IPv6 Neighbor Discovery on Wireless Networks" draft

Hello Brian:

>>> 1- You say " But in reality, IPv6 multicast messages are typically broadcast on the wireless medium, and so they are processed by most of the wireless nodes over the subnet (e.g., the ESS fabric).” most, some or all nodes?

>> That’s most. Ideally a broadcast would reach all nodes, but on Wi-Fi there’s no retry for broadcast. When a node sends a broadcast packet, only a portion of the nodes actually get it.

> My experience a few IETFs ago was that the chance of a given link-local multicast getting through was about 10%, even when the sending host was sitting next to the receiving host in the same room. On investigation, this was because the NOC's throttling policy in the switches was pretty strong, as you would expect for a network like the IETF's. By contrast, on my home network the chances seem to be close to 100%. So I think the text needs a YMMV warning, even if "most" is indeed typical. More below...

We did a recent measure on the wire on a large conference and found 300 ND multicasts per second on the wire for 90 minutes in a row. Obviously throttling is needed otherwise that would saturate the wireless. But then, there are as many ways of throttling in the fabric as there are vendors, and that's because *we* failed to address the issue. 

The IPv6 ND as designed in the end of the last century by the IETF does not work anymore on the IETF's own network and we do not even react. So vendors apply special sauce that turns the switches into one new form of our beloved middle boxes. This is a very active proprietary medicine that saves the network at a cost that is not well understood. You found it affects DAD, but also other aspects of ND, and multicast protocols in general. It may also be on the way of future enhancements that 'middle box' undocumented behaviors in old switches may block. 

I've heard that the phones also throttle, to preserve their battery. I've observed that my phone depletes much faster at IETF than at home, even with the LTE off. We are collectively guilty of that situation by our failure to adapt so far. It is high time 6MAN considers the IPv6 over wireless problem more seriously, starting with the basic building block, IPv6 ND, and RFC 8505 is a good place to begin.

Take care,

Pascal

> The root of my work on RPL was actually for cars, if you’re aware of the nested NEMO problem. RPL optimizes the amount of control at the expense of a routing stretch when not talking to the root. This is good for lower power nodes because it saves energy. But this is also great for mobile nodes such as cars that really over one another to reach the internet, because RPL filters out what they do not want to know like which are all the other cars, what topology is built to reach out, and all the mobility that takes place between them.
> 
>  
> 
> Many tahks again for you excellent comments : )
> 
>  
> 
> Pascal
> 
>  
> 
> *From:*ipv6 <ipv6-bounces@ietf.org> *On Behalf Of *Nabil Benamar
> *Sent:* mardi 24 septembre 2019 23:06
> *To:* ipv6@ietf.org
> *Subject:* On the "IPv6 Neighbor Discovery on Wireless Networks" draft
> 
>  
> 
> 
> Hi Pascal,
> 
>  
> 
> I would like to ask you some questions about your interesting draft.
> 
>  
> 
> 1- You say " But in reality, IPv6 multicast
> 
>    messages are typically broadcast on the wireless medium, and so they
> 
>    are processed by most of the wireless nodes over the subnet (e.g.,
> 
>    the ESS fabric).
> 
>  
> 
> most, some or all nodes?
> 
>  
> 
> 2- In the text you mentioned IEEE 802.11p. You need to replace it by IEEE 802.11-OCB since the 'p' is no more used by IEEE and it has been replaced by OCB.
> 
> See https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-52
> 
>  
> 
> 3- I think there are some duplications in the text about the fact that "....
> 
>    in all the cases in this specification, the Layer-3 multicast
> 
>    operation is always a MAC_Layer broadcast for the lack of a Layer-2
> 
>    multicast operation that could handle a possibly very large number ofgroups in order to make the unicast efficient.."
> 
> Already mentioned in the introduction section.
> 
>  
> 
> 4- You mentionned the example of cars using RPL (Route-Over MLSN)
> 
> I think that cars do not belong to LLNs category.
> 
>  
> 
>  
> 
> Yours.
> 
>  
> 
> Best regards
> 
> Nabil Benamar
> 
> -------------------
> 
> نبيل بنعمرو
> 
>  
> 
>  
> 
>  
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 