<p dir="ltr">Hi Spyros</p>
<p dir="ltr">Based on your answer, I see where the fundamental problem is.<br>
Unlike ndn-cxx APIs which usually follows a "deprecation => dependant projects fixes => removal" procedure, NFD APIs are all considered "internal". This means, when we change NFD, we do not consider backwards-compatibility (except for updates that changes protocol semantics), and will delete old APIs immediately when some refactoring is needed.<br>
The arise of ndnSIM 2.x breaks this "internal API" assumption: ndnSIM effectively becomes as a dependent project of NFD. Every time NFD introduces a backwards-incompatible change, it will potential break ndnSIM.</p>
<p dir="ltr">Requiring a deprecation-fixes-removal cycle into NFD workflow is possible, but it would introduce significant overhead onto NFD development.<br>
However, the alternative is what's happening now: ndnSIM uses a severely outdated version of NFD, and thus cannot keep up with the needs of the community. I personally rejected using ndnSIM and chose Mininet or plain ns-3 in several projects because of this.</p>
<p dir="ltr">It's well known that Google Inc uses a single codebase for all its software, so that everything is always compatible. I think this shall be the ultimate goal of NDN platform development workflow, although it's still a long way to go.</p>
<p dir="ltr">Back to the current situation, my opinion is: ndnSIM should be kept up with NFD more frequently to satisfy community needs, at the granularity of monthly or even weekly, even at the cost of slowing down NFD feature development. This would expose the incompatibility problems early and get them resolved early.<br>
As decided in Jan 2014 NFD planning meeting, compatibility with simulation of a design goal on NFD roadmap, although it's decided that this goal is ignored in NFD 0.1 release. It's time to revisit this goal and resolve this problem.</p>
<p dir="ltr">Yours, Junxiao</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Oct 29, 2016 14:54, "Spyridon (Spyros) Mastorakis" <<a href="mailto:mastorakis@cs.ucla.edu">mastorakis@cs.ucla.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Junxiao,<div><br></div><div>every time that I have tried to upgrade the version of NFD and ndn-cxx used by ndnSIM, there have been a number of unexpected things that go wrong. Some of them have to do with ndnSIM itself, some of them with NS3.</div><div><br></div><div>Like I said before, it is not clear to me right now which NFD features might be incompatible with ndnSIM and I do not want to respond to something that I am not 100% sure about. The way to figure out is to upgrade NFD and try to compile ndnSIM. At that point, a number of things will break. Some of them will be trivial to fix, some other not.</div><div><br></div><div>I am sorry, but this is the best answer I can give you right now.</div><div><br></div><div>Spyros</div><div><br><div>
<div><div><div><span style="float:none;display:inline!important">Spyridon (Spyros) Mastorakis</span><br><span style="float:none;display:inline!important">Personal Website: </span><a href="http://cs.ucla.edu/~mastorakis/" target="_blank">http://cs.ucla.edu/~<wbr>mastorakis/</a><br><span style="float:none;display:inline!important">Internet Research Laboratory</span><br><span style="float:none;display:inline!important">Computer Science Department</span><br><span style="float:none;display:inline!important">UCLA</span></div></div></div>
</div>
<br><div><blockquote type="cite"><div>On Oct 29, 2016, at 1:09 PM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>> wrote:</div><br class="m_528376658494927060Apple-interchange-newline"><div><div dir="ltr">Hi Spyros<div>(moved to ndnSIM mailing list)</div><div><br></div><div><div>Is there a document about ns-3 restrictions and patterns?</div></div><div>As I understand, ndnSIM and other modules are required to use RandomVariableStream, Scheduler, Logging as described in <a href="https://www.nsnam.org/docs/release/3.25/manual/html/index.html" target="_blank">ns-3 Manual</a>. Other facilities such as Hash Functions, Callbacks, Object model, Tracing are optional.</div><div><br></div><div>ndn-cxx and NFD 0.5.0 has dropped build support on Ubuntu 12.04. ndnSIM 2.1 already does not support Ubuntu 12.04 unless either compiler or Boost is upgraded.</div><div><br></div><div>ndn-cxx 0.5.0 release notes list the following changes, excluding bugfixes/deprecations/<wbr>deletions and changes in tools:<br></div><div><ol><li>New transformation API (Issue #3009)<br></li><li>Introduce environment variables to set/override transport, pib, and tpm configurations (Issue #2925, Issue #2514)<br></li><li>Introduce logging facility based on Boost.Log (Issue #3562)<br></li><li>Introduce Name::deepCopy to allow memory optimizations when working with Name objects (Issue #3618)<br></li><li>New ndn::security::<wbr>CommandInterestValidator class (Issue #2376)<br></li><li>Add StatusDataset client functionality into ndn::nfd::Controller (Issue #3329)<br></li><li>New FaceUpdateCommand structure for NFD management protocols (Issue #3232)<br></li><li>breaking change Add Flags and Mask fields to faces/create and faces/update, add Flags field to FaceStatus (Issue #3731, Issue #3732)<br></li><li>New SafeBag structure for private key export/import (Issue #3048)<br></li><li>ndn::io::loadBlock and saveBlock (Issue #3741)<br></li><li>Backport of C++17 std::clamp and std::optional (Issue #3636, Issue #3753)<br></li><li>Expose ControlResponse as part of Controller::<wbr>CommandFailCallback (Issue #3739)<br></li><li>Change security constants to corresponding strongly typed enumerations (Issue #3083)<br></li><li>Enable KeyChain customization in DummyClientFace (Issue #3435)<br></li><li>Add validation of StatusDataset and ControlCommand responses in ndn::nfd::Controller (Issue #3653)<br></li><li>Enable handling of NACKs in Validator and NotificationSubscriber classes (Issue #3332, Issue #3662)<br></li><li>Several fixes in Scheduler class (Issue #3722, Issue #3691)<br></li><li>Add option to override processEvents method in DummyClientFace class (Issue #3769)</li></ol></div><div>NFD 0.5.0 release notes list the following changes, excluding bugfixes/deprecations/<wbr>deletions and changes in tools:</div><div><ol><li>Add Adaptive SRTT-based Forwarding strategy (Issue #3566)<br></li><li>Introduce configurable policy for admission of unsolicited data packets into the content store (Issue #2181).</li><li>Introduce mechanism to update properties (e.g., flags, persistency) of an existing Face (Issue #3731).</li><li>Strategy API update. FIB entry is no longer supplied to the Strategy::afterReceiveInterest method (i.e., FIB lookup is not performed by the forwarding pipelines). When necessary, a strategy can request FIB lookup using Strategy::lookupFib (Issue #3664, Issue #3205, Issue #3679, Issue #3205)<br></li><li>ForwarderStatus dataset can now be requested only with /localhost/nfd/status/general interest (Issue #3379)<br></li><li>Optimizations of tables and forwarding, including reduced usage of shared_ptr (Issue #3205, Issue #3164, Issue #3687)<br></li><li>Display extended diagnostic information if NFD crashes (Issue #2541)<br></li><li>Visualize NACK counters in nfd-status output (Issue #3569)<br></li><li>Extend management to process the new LocalFieldsEnabled attribute when creating/updating Faces (Issue #3731)<br></li><li>Switch logging facility to use Boost.Log (Issue #3562)<br></li><li>Refactor implementation of RIB Manager to make it uniform with other managers (Issue #2857)<br></li><li>Miscellaneous code refactoring (Issue #3738, Issue #3164, Issue #3687, Issue #3205, Issue #3608, Issue #3619, Issue #2181)</li></ol></div><div><br></div><div>I wonder what's the major difficulty of integrating NFD 0.5.0 into ndnSIM?</div><div>Can you point out which items are in conflict with ns-3 restrictions and patterns, or what updates have made the compliance situation worse than NFD 0.4.1?</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 29, 2016 at 12:16 PM, Spyridon (Spyros) Mastorakis <span dir="ltr"><<a href="mailto:mastorakis@cs.ucla.edu" target="_blank">mastorakis@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">To clarify things:<div><br></div><div>the upcoming release of ndnSIM (v2.2) will be based on NFD 0.4.1. Our initial goal for the release after ndnSIM 2.2 is to be based on NFD 0.5, however, we really hope that it might be based on the latest (at that time) version of NFD.</div><div><br></div><div>The reason that ndnSIM 2.2 will be based on NFD 0.4.1 and not 0.5 is that NFD 0.5 contains a lot of internal restructuring that is not clear to us how easy or hard would be to integrate with ndnSIM. ndnSIM is based on NS3 and the NS3 world has some certain restrictions and patterns that sometimes make the integration of NFD features really hard.</div><div><br></div><div>I wish we had more manpower to be able to keep up more actively.</div><div><br></div><div>Thank you,</div><div>Spyros</div></div></blockquote></div></div></div></div>
</div></blockquote></div><br></div></div></blockquote></div></div>