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

[Ankur Sood <[e-mail]>]

Hello All,

Please see the comments inline.

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

> Hi Erik,
>
> Please see in-line.
>
> -----Original Message-----
> From: Erik Nordmark [mailto:[e-mail]]
> Sent: Thursday, March 12, 2015 2:22 PM
> To: Samita Chakrabarti; Erik Nordmark ([e-mail])
> Cc: [e-mail]; [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.
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.

(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]
> > https://www.ietf.org/mailman/listinfo/efficientnd-dt
>
>