[Ndn-interest] Network inconsistency and NLSR sequence numbers

WENTAO SHANG wentaoshang at ucla.edu
Mon Aug 26 08:52:17 PDT 2019

On Mon, Aug 26, 2019, 2:19 AM Viktor S. Wold Eide <
viktor.s.wold.eide at gmail.com> wrote:

> On Sat, Aug 24, 2019 at 7:36 AM WENTAO SHANG <wentaoshang at ucla.edu> wrote:
> >
> > On Fri, Aug 23, 2019 at 5:38 AM Viktor S. Wold Eide <
> viktor.s.wold.eide at gmail.com> wrote:
> >>
> >> Thanks a lot everyone for answers with information and suggestions.
> >>
> >> I'll try to summarize my understanding so far. Please let me know if
> >> this is (entirely) correct or not.
> >>
> >> There are at least three main issues which currently make testing and
> >> use of nlsr in a dynamic environment hard / difficult and also
> >> inefficient network-wise.
> >
> > Link state routing is bad for dynamic environment in general. You would
> want something like AODV in those use cases.
> I certainly would like to also have routing that is more geared towards
> dynamic environments. Are there any implementations for Ndn which you
> would recommend that I try out?

We did some work before on running sync as a smart forwarding protocol in
sensor networks but it's based on simulation. I don't know if we have any
implementation that can be readily deployed on real devices...

> <cut>
> >> - nlsr requires periodic global synchronized re-start (stop, wait,
> >>   start) of all nlsr instances in a network, to get rid of old
> >>   information in nlsr / sync. (nfd can be left running during re-start
> >>   of nlsr).
> >
> > Where did you get this conclusion from?
> From own observations, the other answers here, as well as the links
> provided by Junxiao Shi and Ashlesh Gawande.
> Do you know of another way to get rid of information in nlsr/sync,
> that is, information from other nodes that are no longer connected to
> the Ndn network.

My understanding is that removing old data from sync is a separate problem
and is optional for the routing protocol on top of sync.

One way to look at sync is that it is essentially an append only log.
Supporting append only log efficiently on persistent storage is a classic
problem that has been well studied by database and file system researchers.
There are many good ideas that we can borrow from there to improve our
implementation of sync (e.g., Log-Structured Merge).

> >> - nlsr requires synchronized clocks, that is, global time for correct
> >>   operation. (nfd does not seem to require global synchronized
> >>   clocks).
> >
> > Why?
> See another email thread with subject "Ndn clock synchronization
> requirements" from June 11. 2019. Shortly, from testing I did see that
> clock synchronization is required for nlsr to operate correctly. Name
> LSA and adjacent LSA information is ignored when clocks in different
> nodes are to far apart. The LSA information received by a node seem
> to contain a timestamp set at the sender side. However, the receiver
> uses its own local clock to determine if the LSA information is
> outdated or not, which clearly does not work when clocks in different
> nodes are not sufficiently synchronized.
> Hence, I wrote that nlsr requires synchronized clocks, global time for
> correct operation. I have not seen anything so far which indicate that
> nfd itself require synchronized clocks.
> Do you have any other information or do you see it differently?

Folks who know more about implementation detail should chime in on this.
But I think this is probably an optimization in the current implementation
(with additional dependency on synchronized clock) for speeding up


> Best regards
> Viktor S. Wold Eide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20190826/1ccb89d4/attachment.html>

More information about the Ndn-interest mailing list