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

[Erik Nordmark <[e-mail]>]

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 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Erik,
>
>     Please see in-line.
>
>     -----Original Message-----
>     From: Erik Nordmark [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     Sent: Thursday, March 12, 2015 2:22 PM
>     To: Samita Chakrabarti; Erik Nordmark ([e-mail]
>     <mailto:[e-mail]>)
>     Cc: [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>
>     Subject: Re: [Efficientnd-dt] ND related test results draft
>
>     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.
>
>     [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.
>
>
>     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.
>
>
> [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.
>     Ankur might have details on that.
>
>
> [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
>
>
>
>
>
>     > 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-da
>     > d-test-00.txt
>     > > Status:
>     > >
>     >
>     https://datatracker.ietf.org/doc/draft-sood-6man-nd-signalling-n-dad-t
>     > est/
>     > > 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.
>     >
>     >
>     >
>     > _______________________________________________
>     > Efficientnd-dt mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/efficientnd-dt
>
>