<div dir="ltr"><div dir="ltr">Hi Jeff,<div><br></div><div>Please see the following link for the latest SVS (the new DDSN) implementation:</div><div><br></div><div><a href="https://github.com/named-data/ndn-svs">https://github.com/named-data/ndn-svs</a><br></div><div><br></div><div>Regards,</div><div>Zhaoning</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 21, 2021 at 1:46 PM Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><br><blockquote type="cite">On Feb 21, 2021, at 9:51 AM, White, Jeff via Ndn-interest <ndn-<a href="mailto:interest@lists.cs.ucla.edu" target="_blank">interest@lists.cs.ucla.edu</a>> wrote:<br><br>Dell Customer Communication - Confidential<br></blockquote><br>This exchange is on a public mailing list, so I assuming nothing I can be confidential :-)<div><div><br></div><blockquote type="cite">Hell NDN Community:<br> <br>We are working on a research problem and I noted DDSN has some very desirable aspects for solving our challenge.<br></blockquote><div><br></div>Great to hear.</div><div>BTW we renamed and revised DDSN to SVS, state-vector sync (simpler), and made a new spec and implementation (hope someone could help with a pointer)</div><div><br></div><div>Below are just some personal view; others may chip in with different opinions.</div><div> <br><blockquote type="cite">Two questions:<br> <br><div><span style="white-space:pre-wrap"> </span>• How is group membership regulated – how do you join a DDSN group? How do you exit?<br></div></blockquote><div><br></div>1/ Group membership is really app level decision, not by the protocol.</div><div><br></div><div>2/ physically a member just needs to be able to send and receive the sync interest.</div><div><ul><li>Sending: requires one be a legit member (i.e. get necessary crypto credential);</li><li>Receiving: ideally the network should be doing multicast delivery of sync interests to only the group members, that require members make necessary routing announcements and forwarders use multicast strategy (to cheat in a small setting, forwarders could just broadcast anything that they suppose to apply multicast strategy)</li></ul><div>Exit: you mean kicking someone out? Just revoke the credential</div></div><div><br></div><div><blockquote type="cite"><div><span style="white-space:pre-wrap"> </span>• I remember from Vectorsync that scale in terms of membership could be an issue as the state vector increases linearly with number of participants. Is this an issue for DDSN, what is the practical limit in group size?</div></blockquote><div><br></div>If you meant the original vectorsync: its sync interests carry an ordered list of the latest seq# of each producer, without producer names.</div><div>Started from DDSN (now SVS), the protocol uses a state vector of [producer, seq#]. This change not only removed the need for strict synchronization of the membership among all the participants all the time, but also opened the door of letting each sync interest carry a partial, instead of complete, state vector.<br><div><br></div><blockquote type="cite">Any insight would be helpful.<br></blockquote><div><br></div>Curious what kind of problems you are thinking about applying SVS to.</div><div><br></div><div>Lixia</div><div><br></div></div>_______________________________________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
</blockquote></div>