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

From: Nabil Benamar <[email-masked]>
Date: Tue, 24 Sep 2019 22:05:55 +0100

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
-------------------
نبيل بنعمرو

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 25 Sep 2019 09:22:06 +0000

Hello Nabil :

Many thanks for your questions and interest:

> 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. Some miss it because they fail to decode the packet at the PHY layer, others because of throttling policies that drop the broadcast low in the stack to protect the battery. This is why DAD often fails to detect duplicates.

> 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

Yes, I’ll fix that with the next revision.

> 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.

True, I’ll fix that too 😊

> 4- You mentionned the example of cars using RPL (Route-Over MLSN) I think that cars do not belong to LLNs category.

I would not argue about whether car networks are LLN or not, because I think that matters little: the bottom line is that RPL is a generic DV layer-3 protocol, agnostic of the particular links (the OF takes the hit)  and it is applicable beyond ultra-low power links.

We have an implementation on ethernet for ANIMA. 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 <[email-masked]> On Behalf Of Nabil Benamar
Sent: mardi 24 septembre 2019 23:06
To: [email-masked]
Subject: On the "IPv6 Neighbor Discovery on Wireless Networks" draft

Hi Pascal,

   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.

   multicast operation that could handle a possibly very large number ofgroups in order to make the unicast efficient.."

Yours.

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Sep 2019 08:43:49 +1200

Hi Pascal,

On 25-Sep-19 21:22, Pascal Thubert (pthubert) wrote:
> 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...

> Some miss it because they fail to decode the packet at the PHY layer, others because of throttling policies that drop the broadcast low in the stack to protect the battery. This is why DAD often fails to detect duplicates.
> 
> We have an implementation on ethernet for ANIMA. 

Have we seen that at a hackathon? The "victim" of the throttling I mentioned above was my prototype of the ANIMA GRASP protocol, but running unsecured over the raw layer 2 network.
I'd love to run it over a RPL substrate. (Reply off list if you prefer.)

   Brian

> 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.
> 
>  
> 
> *From:*ipv6 <[email-masked]> *On Behalf Of *Nabil Benamar
> *Sent:* mardi 24 septembre 2019 23:06
> *To:* [email-masked]
> *Subject:* On the "IPv6 Neighbor Discovery on Wireless Networks" draft
> 
>  
> 
> 
> Hi Pascal,
> 
>  
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 26 Sep 2019 08:36:21 +0000

> 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.…

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 26 Sep 2019 10:48:15 +0200

Le 26/09/2019 à 10:36, Pascal Thubert (pthubert) a écrit :
> I've observed that my phone depletes much faster at IETF than at home, 

smartphones deplete faster in areas surronded by concrete (large 
hotels), where no indoor cellular repeaters are present.   And also in 
trains, cars, plains and in tunnels.

To make statements about ND multicast guilt part of this fast depletion 
one would need to identify it precisely.

Remember that smartphones deplete faster on IPv6 than on IPv4, as we 
identified and reported in draft-petrescu-v6ops-ipv6-power-ipv4-00.txt

Alex

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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 26 Sep 2019 14:45:56 +0000

Very interesting reading Alex.

The part I'd be most interested in is the amount and ratio of wireless bandwidth (air time) and of battery that's wasted, e.g., receiving L2 broadcast packets when the node is not a L3 destination of the multicast message. It is  aknown problem but we do not have a good panel of experimentation with results like: amount of such messages per unit of time in various situations, average transmission time (PHY speed) in different cases like e.g., home, SoHo, coffee shop, mall, large conf, IETF plenary. 

I think that ND vs. ARP is not even battery wise; I'm afraid that IPv6 is a lot worse.

All the best

Pascal

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: jeudi 26 septembre 2019 10:48
To: [email-masked]
Subject: Re: On the "IPv6 Neighbor Discovery on Wireless Networks" draft

To make statements about ND multicast guilt part of this fast depletion one would need to identify it precisely.

Remember that smartphones deplete faster on IPv6 than on IPv4, as we identified and reported in draft-petrescu-v6ops-ipv6-power-ipv4-00.txt

Alex

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.
>> See 
>> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-52
>>
>>   
>>