Hi, Yao.
Retrans Timer is described in not seconds but milliseconds, isn't it?
I still feel that 1 second timer is too large for Retrans Timer granularity.
I'm not the implementor,
so I can't imagine about the implementation limitation.
Only I can do is just understanding what RFC says. :-)
Hopefully,
please give comments about this. > all
Thanks,
On Wed, 06 Feb 2008 08:55:52 -0700
Yinghui Yao <Yinghui.Yao@alcatel-lucent.com> wrote:
> Hi Akisada-san,
>
> According to the RFC, the retransmission must be limited to at most 1
> per retrans time. Considering most implementations probably run in 1
> second timer, I think 1-2 seconds between NS should be tolerated.
>
> Thanks,
> Yinghui Yao
> Alcatel-Lucent.
>
> Yukiyo Akisada wrote:
> > Hi, Yao.
> >
> > ND #8 and #9 for the router is Test v6LC.2.1.5.
> > Please don't believe filename.
> >
> > Inconveniently,
> > the actual test title (Test v6LC.X.X.X) was renumberd
> > in the past update of specification.
> >
> > You can see the actual test title
> > in <report.html> generated by the tester.
> > It's the right side of the HTML frame.
> >
> > Anyway,
> > our tester already incerted plus-minus 0.5 sec margin.
> > It means half adjust.
> > Totally 1 sec margin is enough for approximately, I think.
> > Half adjust is commonly used to know approximately velue, isn't it?
> >
> > Conformance tester only knows the external behavior.
> > And the tester couldn't support
> > every internal behaviors of implementation in the world.
> >
> > How do you think?
> >
> > One of solutions is that you submit the logo application including FAILs.
> > Your reason can be good reason to omit SHOULD.
> > If IPv6 Ready Logo Committee accept it, you get the logo.
> > But in this case,
> > this behavior will be described on Latest approved list.
> >
> > Logo ID 02-C-000213 is the good case at
> > <http://www.ipv6ready.org/logo_db/approved_list_p2.php>.
> > The behavior is also described on their site.
> >
> > Thanks,
> >
> >
> > On Tue, 05 Feb 2008 10:44:23 -0700
> > Yinghui Yao <Yinghui.Yao@alcatel-lucent.com> wrote:
> >
> >
> >> Hi Yukiyo,
> >>
> >> I disagree to the "judgment"s TAHI uses in these two tests (V6LC.2.1.6).
> >>
> >> I assume the test is based on the statement in RFC 4861, section 7.2.2
> >>
> >> "
> >> While awaiting a response, the sender SHOULD retransmit Neighbor
> >> Solicitation messages *approximately* every RetransTimer milliseconds,
> >> even in the absence of additional traffic to the neighbor.
> >> Retransmissions MUST be rate-limited to at most one solicitation per
> >> neighbor every RetransTimer milliseconds.
> >>
> >> "
> >>
> >> Could you let me know how TAHI defines "approximately" in your tests? We
> >> observe 1.3 second between NS will pass and 1.6 would fail.
> >>
> >> Our router has to handle large number of NDs, so our ND timer only runs
> >> every 1 second. Depending on when the echo request comes into the NUT,
> >> the time gap between our first and second NS can be anywhere between 1-2
> >> seconds. However the time gap between 2nd NS and 3rd NS is always 1
> >> second. So we could have
> >>
> >> NS(at 0 second) - NS (at 1.6 second) - NS (at 2.6 second) (retrans = 1s)
> >>
> >> NS(at 0 second) - NS (at 5.5 second) - NS (at 10.5 second) (retrans = 5s)
> >> We think these two packet sequences do satisfy the above RFC requirement
> >> and should pass. However TAHI are failing both. We think it's wrong.
> >>
> >> Could you let me know if my argument is valid and if you are willing to
> >> make changes to accommodate our scenarios in TAHI code?
> >>
> >> Thanks,
> >> Yinghui Yao
> >> Alcatel-Lucent
> >>
> >>
> >
> >
> > ------------------------------------------------------------------------
> > Yukiyo Akisada <akisada@tahi.org>
> >
>
>
------------------------------------------------------------------------
Yukiyo Akisada <akisada@tahi.org>