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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Alexandre Petrescu
Sent: jeudi 26 septembre 2019 10:48
To: [e-mail]
Subject: Re: On the "IPv6 Neighbor Discovery on Wireless Networks" draft



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.
> 
> 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 <[e-mail]> *On Behalf Of *Nabil Benamar
>> *Sent:* mardi 24 septembre 2019 23:06
>> *To:* [e-mail]
>> *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
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------