Subject: [Efficientnd-dt] ND related test results draft

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 9 Mar 2015 23:18:33 +0000

Hello Erik and all:

A draft has been published by Ankur Sood (from North Carolina State University); Ankur had done some simple tests with ND routers(linux Ubuntu), a  non-intelligent Wifi access point which sends data back and forth towards and from the wireless hosts ( two wifi phone devices and a laptop ).

The purpose of this draft is to see how RA messages can increase with the frequency of interval and the difference between min and MAX advinterval. Also how different sleeping host implementations behave differently  around ND and DAD.

Perhaps it could provide some data point for DAD issues as well.  I have CC'ed Ankur if  anyone has any questions/suggestions for him.

-Samita

>Name:           draft-sood-6man-nd-signalling-n-dad-test
> Revision:       00
> Title:          Test result analysis of IPv6 Neighbor Discovery in a
> simple Wireless network
> Document date:  2015-03-09
> Group:          Individual Submission
> Pages:          14
> URL:
> http://www.ietf.org/internet-drafts/draft-sood-6man-nd-signalling-n-dad-test-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-sood-6man-nd-signalling-n-dad-test/
> Htmlized:
> http://tools.ietf.org/html/draft-sood-6man-nd-signalling-n-dad-test-00
>
>
> Abstract:
>    IPv6 WG is looking into various Neighbor Discovery (ND) optimization
>    techniques.  This document describes several test cases and test
>    results on IPv6 ND number of messages, power usages using simple WiFi
>    configuration and wireless phones as hosts.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 12 Mar 2015 14:21:48 -0700

On 3/9/15 4:18 PM, Samita Chakrabarti wrote:
>
> Hello Erik and all:
>
> A draft has been published by Ankur Sood (from North Carolina State 
> University); Ankur had done some simple tests with ND routers(linux 
> Ubuntu), a  non-intelligent Wifi access point which sends data back 
> and forth towards and from the wireless hosts ( two wifi phone devices 
> and a laptop ).
>
> The purpose of this draft is to see how RA messages can increase with 
> the frequency of interval and the difference between min and MAX 
> advinterval. Also how different sleeping host implementations behave 
> differently  around ND and DAD.
>
The part about the different behavior of of the hosts is quite 
informative. I think this is an area we should understand better to see 
how the implementation choices affect the network behavior.

Changing maxRa and not minRa seems less useful than changing one and 
keeping the max:min ratio constant. One would expect that with a 
constant ratio between them the RA rate would be proportional to the 
timers. However, I can't easily check if that is the case from the 
results due to the change in ratio. (And if there are additional hosts 
one would expect to see RAs caused by sending RS as they connect; many 
router implementations multicast those solicited RAs.)

I didn't quite understand the last part about changing the lifetime. 
That should not affect when RAs are transmitted (which the results show).

Thanks,
    Erik

> Perhaps it could provide some data point for DAD issues as well.  I 
> have CC’ed Ankur if anyone has any questions/suggestions for him.
>
> -Samita
>
> _______________________________________________
> Efficientnd-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/efficientnd-dt

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 13 Mar 2015 00:24:11 +0000

Hi Erik,

Please see in-line.

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Thursday, March 12, 2015 2:22 PM
To: Samita Chakrabarti; Erik Nordmark ([email-masked])
Cc: [email-masked]; [email-masked]
Subject: Re: [Efficientnd-dt] ND related test results draft

> differently  around ND and DAD.
The part about the different behavior of of the hosts is quite informative. I think this is an area we should understand better to see how the implementation choices affect the network behavior.

[SC>]  Most importantly the sleepy behavior of the two wireless phones' implementations  and  anomaly in response to DAD messages. 

Changing maxRa and not minRa seems less useful than changing one and keeping the max:min ratio constant. One would expect that with a constant ratio between them the RA rate would be proportional to the timers. However, I can't easily check if that is the case from the results due to the change in ratio. (And if there are additional hosts one would expect to see RAs caused by sending RS as they connect; many router implementations multicast those solicited RAs.)
[SC>]   Yes, many implementation still multicast the solicited RA - I think that might be the case for this Ubuntu implementation too. Ankur-- do you remember?

I didn't quite understand the last part about changing the lifetime. 
That should not affect when RAs are transmitted (which the results show).
[SC>]  The advlifetime column is  kind of lame here.  Originally the plan was to observe the  node behavior  when RA interval is increased to  >= Advlifetime.  But  that was not possible from the configuration file [ did not allow]. So I believe Ankur tried changing default-lifetime just for experiment's sake . The change in number (increment) in RA is probably due to  increased time duration.

Also one observation was made (not listed in the draft) that  over several hours of duration only 2/% - 3% battery was consumed when the phone is left idle and periodic RA messages were sent. But the accuracy of the experiment was not clear. Perhaps it is because the phone sleeps and they don't listen to any of the multicast ND messages.
Ankur might have details on that.
Thanks,
-Samita

> have CC'ed Ankur if anyone has any questions/suggestions for him.
>
> -Samita
>

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 12 Mar 2015 20:26:50 -0700

> Also one observation was made (not listed in the draft) that  over several hours of duration only 2/% - 3% battery was consumed when the phone is left idle and periodic RA messages were sent. But t…
One could design tests to check if the phone receives and processes the 
RA. Just have the router send a single RA with a new prefix and with a 
long prefix lifetime. Later one can check for the existence of that 
prefix on the phone.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 14 Mar 2015 00:05:13 -0700

On 3/13/15 7:53 PM, Ankur Sood wrote:
> Hello All,
>
> Please see the comments inline.
>
> On Thu, Mar 12, 2015 at 8:24 PM, Samita Chakrabarti 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Erik,
>
>     Please see in-line.
>
>     From: Erik Nordmark [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     To: Samita Chakrabarti; Erik Nordmark ([email-masked]
>     <mailto:[email-masked]>)
>     Cc: [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     informative. I think this is an area we should understand better
>     to see how the implementation choices affect the network behavior.
>
>     [SC>]  Most importantly the sleepy behavior of the two wireless
>     phones' implementations  and  anomaly in response to DAD messages.
>
>     Changing maxRa and not minRa seems less useful than changing one
>     and keeping the max:min ratio constant. One would expect that with
>     a constant ratio between them the RA rate would be proportional to
>     the timers. However, I can't easily check if that is the case from
>     the results due to the change in ratio. (And if there are
>     additional hosts one would expect to see RAs caused by sending RS
>     as they connect; many router implementations multicast those
>     solicited RAs.)
>     [SC>]   Yes, many implementation still multicast the solicited RA
>     - I think that might be the case for this Ubuntu implementation
>     too. Ankur-- do you remember?
>
> [AS] As far as I remember, all the RA's were multicast.
>
>
>     [SC>]  The advlifetime column is  kind of lame here.  Originally
>     the plan was to observe the  node behavior  when RA interval is
>     increased to  >= Advlifetime.  But  that was not possible from the
>     configuration file [ did not allow]. So I believe Ankur tried
>     changing default-lifetime just for experiment's sake . The change
>     in number (increment) in RA is probably due to  increased time
>     duration.
>
>
> [AS] From this test case, I intend to show that as the difference 
> between [Max/Min]RtrAdvInterval increases, the number of RA messages 
> transmitted almost remains the same except for the initial case when 
> the difference between [Max/Min]RtrAdvInterval is very small.
>
> (1) Taking the default values,
>
> MinRtrAdvInterval = 3 sec.

That isn't the default value. RFC4861 says
Default: 0.33 * MaxRtrAdvInterval

Thus it would be 600 in this case.
> MaxRtrAdvInterval = 1800 sec,
> AdvDefaultLifetime = 3*MaxRtrAdvInterval = 5400 sec.
>
> So here the RA messages would be sent at any random interval between 
> 3sec. - 1800 sec. Now if we assume that the default router fails, the 
> hosts will still consider it as the default router for the next 5400 
> sec. until a new pefix is advertised.
>
> (2) Now if we take the below values,
>
> MinRtrAdvInterval = 3 sec.
> MaxRtrAdvInterval = 100 sec.
> AdvDefaultLifetime = 3*MaxRtrAdvInterval = 300 sec.
>
> So here, when the router fails, then the switchover to another router 
> would be faster.

When a router fails then NUD will detect it (assuming the host is 
sending something) in about 45 seconds and fail over to another default 
router.
And if failover is critical then it is normal to use VRRP to get the 
failover time down to a few seconds if not less.

Regards,
    Erik

>
> (3) Also in this test case, I observed that the number of RA messages 
> exchanged is almost the same except for 30/50 sec value. I observed 
> that the MaxRtrAdvInterval is not being considered while sending RAs, 
> otherwise the number of RA messages transmitted would have been 
> different. So MaxRtrInterval should be kept at a lower value so that 
> switchover, in the case of router failure, is faster.
>
>     Also one observation was made (not listed in the draft) that over
>     several hours of duration only 2/% - 3% battery was consumed when
>     the phone is left idle and periodic RA messages were sent. But the
>     accuracy of the experiment was not clear. Perhaps it is because
>     the phone sleeps and they don't listen to any of the multicast ND
>     messages.
> [AS] I observed the battery drain to be around 2-3% when there were no 
> applications running on the phone. But it's not clear what other 
> processes consume the battery apart from the multicast ND messages
>
> Thanks & Best Regards,
> Ankur Sood
>
>
>
>
>
>     > [email-masked] <mailto:[email-masked]>

---

From: Ankur Sood <[email-masked]>
Date: Fri, 13 Mar 2015 22:53:26 -0400

Hello All,

On Thu, Mar 12, 2015 at 8:24 PM, Samita Chakrabarti <
[email-masked]> wrote:

> informative. I think this is an area we should understand better to see how
> the implementation choices affect the network behavior.
>
> [SC>]  Most importantly the sleepy behavior of the two wireless phones'
> implementations  and  anomaly in response to DAD messages.
>
> keeping the max:min ratio constant. One would expect that with a constant
> ratio between them the RA rate would be proportional to the timers.
> However, I can't easily check if that is the case from the results due to
> the change in ratio. (And if there are additional hosts one would expect to
> see RAs caused by sending RS as they connect; many router implementations
> multicast those solicited RAs.)
> [SC>]   Yes, many implementation still multicast the solicited RA - I
> think that might be the case for this Ubuntu implementation too. Ankur-- do
> you remember?
>

> [SC>]  The advlifetime column is  kind of lame here.  Originally the plan
> was to observe the  node behavior  when RA interval is increased to  >=
> Advlifetime.  But  that was not possible from the configuration file [ did
> not allow]. So I believe Ankur tried changing default-lifetime just for
> experiment's sake . The change in number (increment) in RA is probably due
> to  increased time duration.
>

[AS] From this test case, I intend to show that as the difference between
[Max/Min]RtrAdvInterval increases, the number of RA messages transmitted
almost remains the same except for the initial case when the difference
between [Max/Min]RtrAdvInterval is very small.

So here the RA messages would be sent at any random interval between 3sec.
- 1800 sec. Now if we assume that the default router fails, the hosts will
still consider it as the default router for the next 5400 sec. until a new
pefix is advertised.

So here, when the router fails, then the switchover to another router would
be faster.

(3) Also in this test case, I observed that the number of RA messages
exchanged is almost the same except for 30/50 sec value. I observed that
the MaxRtrAdvInterval is not being considered while sending RAs, otherwise
the number of RA messages transmitted would have been different. So
MaxRtrInterval should be kept at a lower value so that switchover, in the
case of router failure, is faster.

Also one observation was made (not listed in the draft) that  over several
> hours of duration only 2/% - 3% battery was consumed when the phone is left
> idle and periodic RA messages were sent. But the accuracy of the experiment
> was not clear. Perhaps it is because the phone sleeps and they don't listen
> to any of the multicast ND messages.

[AS] I observed the battery drain to be around 2-3% when there were no
applications running on the phone. But it's not clear what other processes
consume the battery apart from the multicast ND messages

Thanks & Best Regards,
Ankur Sood

---

From: Ankur Sood <[email-masked]>
Date: Fri, 13 Mar 2015 23:09:24 -0400

Hello All,

I did check this scenario and the phone processes the new RA with the
chnaged AdvDefaultLifetime..

Thanks & Best Regards,
Ankur Sood

On Thu, Mar 12, 2015 at 11:26 PM, Erik Nordmark <[email-masked]> wrote:

>> several hours of duration only 2/% - 3% battery was consumed when the phone
>> is left idle and periodic RA messages were sent. But the accuracy of the
>> experiment was not clear. Perhaps it is because the phone sleeps and they
>> don't listen to any of the multicast ND messages.
>>
> RA. Just have the router send a single RA with a new prefix and with a long
> prefix lifetime. Later one can check for the existence of that prefix on
> the phone.
>
>   Erik
>
>

---

From: Ankur Sood <[email-masked]>
Date: Sun, 15 Mar 2015 16:28:06 -0400

Hello Erik,

That's right. NUD will detect router failure. However, in this test case I
am getting almost the same number of RA messages for the different values
of [Min/Max]RtrAdvInterval. Would it not be different since the frequency
is made less with the increasing difference between [Min/Max]RtrAdvInterval.

Thanks & Best Regards,
Ankur Sood

On Sat, Mar 14, 2015 at 3:05 AM, Erik Nordmark <[email-masked]> wrote:

> transmitted almost remains the same except for the initial case when the
> difference between [Max/Min]RtrAdvInterval is very small.
>
> - 1800 sec. Now if we assume that the default router fails, the hosts
> will still consider it as the default router for the next 5400 sec. until a
> new pefix is advertised.
>
> When a router fails then NUD will detect it (assuming the host is sending
> something) in about 45 seconds and fail over to another default router.