<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 27, 2019, 12:53 AM Viktor S. Wold Eide <<a href="mailto:viktor.s.wold.eide@gmail.com">viktor.s.wold.eide@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Aug 26, 2019 at 5:52 PM WENTAO SHANG <<a href="mailto:wentaoshang@ucla.edu" target="_blank" rel="noreferrer">wentaoshang@ucla.edu</a>> wrote:<br>
><br>
> On Mon, Aug 26, 2019, 2:19 AM Viktor S. Wold Eide <<a href="mailto:viktor.s.wold.eide@gmail.com" target="_blank" rel="noreferrer">viktor.s.wold.eide@gmail.com</a>> wrote:<br>
>><br>
>> I certainly would like to also have routing that is more geared towards<br>
>> dynamic environments. Are there any implementations for Ndn which you<br>
>> would recommend that I try out?<br>
><br>
><br>
> 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...<br>
<br>
Then there seems to be no other options for routing in Ndn as of<br>
now. Hence, it seems even more important to have a routing<br>
implementation that works.<br>
<br>
I do not see any reasons why nlsr should not be able to handle well an<br>
environment where nodes are added and removed dynamically, as long as<br>
the frequency is low or modest. How well it would handle more high-<br>
frequent changes is of course interesting, but not the issue discussed<br>
here.<br>
<br>
<br>
>> Do you know of another way to get rid of information in nlsr/sync,<br>
>> that is, information from other nodes that are no longer connected to<br>
>> the Ndn network.<br>
><br>
><br>
> My understanding is that removing old data from sync is a separate problem and is optional for the routing protocol on top of sync.<br>
><br>
> 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).<br>
><br>
<br>
I do not quite get the reasoning here.<br>
<br>
The ability to forget / get rid of nodes not seen for a while seems<br>
like one of the most basic characteristics of a routing protocol, in<br>
order to correctly reflect the state of the network.<br>
<br>
A network which never forgets any node seen - I do not see how that is<br>
desirable.<br>
<br>
When choosing data structures for implementing nlsr, then there are<br>
some operations that must be supported. If sync does not support what<br>
a routing protocol needs, then sync is not the right choice or sync<br>
needs to be extended. Exposing the lack of required functionality from<br>
sync into the routing, here the inability to delete / remove nodes,<br>
can hardly be the right choice.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I agree that this is a problem in the current implementation. But at the protocol design level, removing a router from a sync group does not necessarily require stopping the world and garbage-collecting the sync data repo on every single router. E.g., one can do something like publishing a tombstone object to mark that some stale sync user is gone and will never generate new sequence number. (I remember we experimented with some similar ideas on either ChronoChat or NLSR.) In theory one can have a sync protocol that never removes any data from its distributed data collection but still allows applications running on top of it to remove logical entities. I think these two are separate problems that can be (and should be) decoupled from each other.</div><div dir="auto"><br></div><div dir="auto">Wentao</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> 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 convergence.<br>
><br>
<br>
Let's see if anyone with more knowledge chimes in. In my opinion a<br>
design which depends on synchronized clocks is a to strict and far<br>
reaching requirement, but that was/is a separate discussion.<br>
<br>
<br>
Best regards<br>
Viktor S. Wold Eide<br>
</blockquote></div></div></div>