<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><br class=""><blockquote type="cite" class="">On Feb 21, 2021, at 9:51 AM, White, Jeff via Ndn-interest <ndn-<a href="mailto:interest@lists.cs.ucla.edu" class="">interest@lists.cs.ucla.edu</a>> wrote:<br class=""><br class="">Dell Customer Communication - Confidential<br class=""></blockquote><br class="">This exchange is on a public mailing list, so I assuming nothing I can be confidential :-)<div class=""><div class=""><br class=""></div><blockquote type="cite" class="">Hell NDN Community:<br class=""> <br class="">We are working on a research problem and I noted DDSN has some very desirable aspects for solving our challenge.<br class=""></blockquote><div class=""><br class=""></div>Great to hear.</div><div class="">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 class=""><br class=""></div><div class="">Below are just some personal view; others may chip in with different opinions.</div><div class=""> <br class=""><blockquote type="cite" class="">Two questions:<br class=""> <br class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• How is group membership regulated – how do you join a DDSN group? How do you exit?<br class=""></div></blockquote><div class=""><br class=""></div>1/ Group membership is really app level decision, not by the protocol.</div><div class=""><br class=""></div><div class="">2/ physically a member just needs to be able to send and receive the sync interest.</div><div class=""><ul class=""><li class="">Sending: requires one be a legit member (i.e. get necessary crypto credential);</li><li class="">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 class="">Exit: you mean kicking someone out? Just revoke the credential</div></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </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 class=""><br class=""></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 class="">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 class=""><div class=""><br class=""></div><blockquote type="cite" class="">Any insight would be helpful.<br class=""></blockquote><div class=""><br class=""></div>Curious what kind of problems you are thinking about applying SVS to.</div><div class=""><br class=""></div><div class="">Lixia</div><div class=""><br class=""></div></body></html>