<HTML dir=ltr><HEAD><TITLE>Re: [users:01063] Question about =
V6LC_2_2_14_C in IPv6 Core Protocols 4.0.3</TITLE>
=
<META http-equiv=Content-Type content="text/html; charset=unicode">
=
<META content="MSHTML 6.00.6001.18183" name=GENERATOR></HEAD>
=
<BODY>
=
<DIV id=idOWAReplyText37882 dir=ltr>
=
<DIV dir=ltr><FONT face="Courier New" color=#000000 size=2>I'm =
afraid I don't have any clever ideas about how to determine the =
reachable time. I agree that you can only derive it indirectly from the =
packets sent by the NUT, and I can't think of any way to determine =
how long the NUT is in STALE state.</FONT></DIV>
=
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
=
<DIV dir=ltr><FONT face="Courier New" size=2>Allowing for up to 1 =
ping interval extra in the check, as you suggest, would help avoid false =
failures. Perhaps you could also decrease the interval between pings (to =
0.5 seconds, for example), to reduce the amount of extra time the test =
allows to a minimum.</FONT></DIV>
=
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
=
<DIV dir=ltr><FONT face="Courier New" =
size=2>Peter</FONT></DIV></DIV>
=
<DIV dir=ltr><BR>
=
<HR tabIndex=-1>
=
<FONT face=Tahoma size=2><B>From:</B> ext Yukiyo Akisada =
[mailto:akisada@tahi.org]<BR><B>Sent:</B> Tue 1/6/2009 5:00 =
PM<BR><B>To:</B> Hunt Peter (Nokia-S/MtView)<BR><B>Cc:</B> =
users@tahi.org<BR><B>Subject:</B> Re: [users:01063] Question about =
V6LC_2_2_14_C in IPv6 Core Protocols 4.0.3<BR></FONT><BR></DIV>
=
<DIV>
=
<P><FONT size=2>Hi, Peter.<BR><BR>Thanks for reporting.<BR><BR>The =
resolution of time is always the problem on our tool.<BR><BR>Now the =
tool is repeating transmission of Echo Request and waiting packets =
alternately.<BR>I guess that every "waiting packets" steps are the =
bottleneck.<BR>Maybe this sequence must be somehow optimized.<BR><BR>In =
this moment,<BR>I'm planning to separate transmission loop and waiting =
loop in the source code.<BR>Because v6eval can record every received =
packts,<BR>examining received packts can be done after sending every =
Echo Requests.<BR><BR>And talking about RFC description and how to =
calculate,<BR>your interpretation is right.<BR>But I don't have any =
other idea to calculate the reachable time<BR>only by receiving packet =
from NUT.<BR><BR>This is not the fundamental solution,<BR>but I think =
that optimizing the sequence above<BR>and applying the margin for the =
interval of Echo Request will improve it.<BR><BR>Or, if you have a good =
idea to calculate the reachable time by other way,<BR>please let me =
know.<BR><BR>Thanks,<BR><BR><BR>On Tue, 6 Jan 2009 23:04:47 =
+0200<BR><Peter.Hunt@nokia.com> wrote:<BR><BR>> <BR>> =
I'm running into a problem with one of the tests in the IPv6 Core =
Protocols test suite in the following =
configuration:<BR>> <BR>> =
TN: =
FreeBSD 6.3-RELEASE<BR>> Test Tool: =
v6eval-3.1.0<BR>> Package: IPv6 =
Core Protocols Self_Test_4-0-3<BR>> <BR>> Running the router =
tests (i.e. "make ipv6ready_p2_router").<BR>> <BR>> I'm =
seeing a failure with test "V6LC_2_2_14_C - Reachable Time =
Configuration", which I think may be due to an error in the way the test =
script measures the reachable time. I suspect the test script is not =
accounting for the time in which the ND entry is in "STALE" =
state.<BR>> <BR>> If I'm reading the RFC correctly, the ND =
entry should go through the following states on the =
NUT:<BR>> <BR>> 1) Enters REACHABLE state when NA received =
(and first echo reply sent)<BR>> 2) Enters STALE state ReachableTime =
milliseconds after NA received.<BR>> 3) Enters DELAY state when first =
echo reply sent after entering STALE state.<BR>> 4) Enters PROBE =
state 5 seconds after entering DELAY state (sends first =
NS)<BR>> <BR>> The test calculates the reachable time as the =
interval between the first echo reply sent at 1) and the first NS sent =
at 4), minus 5 seconds. However, this calculation does not account for =
the time that the entry was in STALE state (i.e. the interval between =
the entry entering STALE state and the reception of the next echo =
request).<BR>> <BR>> This error results in the reachable time =
calculation being too large, by up to the interval between echo requests =
sent by the TN. When the random reachable time is close to 15, this =
miscalculation results in the test failing.<BR>> <BR>> I'm =
also seeing a problem where the TN sends echo requests at intervals of =
up to 1.5 seconds, which makes this problem worse.<BR>> <BR>> =
Best regards,<BR>> Peter Hunt<BR>> Software Engineer<BR>> Nokia =
S&S<BR>><BR><BR><BR>--<BR>Yukiyo Akisada =
<akisada@tahi.org><BR></FONT></P></DIV></BODY></HTML>