[ndnSIM] ndnSIM based on NFD 0.5.0

Sat Oct 29 15:38:02 PDT 2016

Hi Spyros

Based on your answer, I see where the fundamental problem is.
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.
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.

Requiring a deprecation-fixes-removal cycle into NFD workflow is possible,
but it would introduce significant overhead onto NFD development.
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.

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.

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.
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.

Yours, Junxiao

On Oct 29, 2016 14:54, "Spyridon (Spyros) Mastorakis" <
mastorakis at cs.ucla.edu> wrote:

> Junxiao,
>
> 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.
>
> 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.
>
> I am sorry, but this is the best answer I can give you right now.
>
> Spyros
>
> Spyridon (Spyros) Mastorakis
> Personal Website: http://cs.ucla.edu/~mastorakis/
> Internet Research Laboratory
> Computer Science Department
> UCLA
>
> On Oct 29, 2016, at 1:09 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> Hi Spyros
> (moved to ndnSIM mailing list)
>
> Is there a document about ns-3 restrictions and patterns?
> As I understand, ndnSIM and other modules are required to use
> RandomVariableStream, Scheduler, Logging as described in ns-3 Manual
> <https://www.nsnam.org/docs/release/3.25/manual/html/index.html>. Other
> facilities such as Hash Functions, Callbacks, Object model, Tracing are
> optional.
>
> 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.
>
> ndn-cxx 0.5.0 release notes list the following changes, excluding
> bugfixes/deprecations/deletions and changes in tools:
>
>    1. New transformation API (Issue #3009)
>    2. Introduce environment variables to set/override transport, pib, and
>    tpm configurations (Issue #2925, Issue #2514)
>    3. Introduce logging facility based on Boost.Log (Issue #3562)
>    4. Introduce Name::deepCopy to allow memory optimizations when working
>    with Name objects (Issue #3618)
>    5. New ndn::security::CommandInterestValidator class (Issue #2376)
>    6. Add StatusDataset client functionality into ndn::nfd::Controller
>    (Issue #3329)
>    7. New FaceUpdateCommand structure for NFD management protocols (Issue
>    #3232)
>    8. breaking change Add Flags and Mask fields to faces/create and
>    faces/update, add Flags field to FaceStatus (Issue #3731, Issue #3732)
>    9. New SafeBag structure for private key export/import (Issue #3048)
>    10. ndn::io::loadBlock and saveBlock (Issue #3741)
>    11. Backport of C++17 std::clamp and std::optional (Issue #3636, Issue
>    #3753)
>    12. Expose ControlResponse as part of Controller::CommandFailCallback
>    (Issue #3739)
>    13. Change security constants to corresponding strongly typed
>    enumerations (Issue #3083)
>    14. Enable KeyChain customization in DummyClientFace (Issue #3435)
>    15. Add validation of StatusDataset and ControlCommand responses in
>    ndn::nfd::Controller (Issue #3653)
>    16. Enable handling of NACKs in Validator and NotificationSubscriber
>    classes (Issue #3332, Issue #3662)
>    17. Several fixes in Scheduler class (Issue #3722, Issue #3691)
>    18. Add option to override processEvents method in DummyClientFace
>    class (Issue #3769)
>
> NFD 0.5.0 release notes list the following changes, excluding
> bugfixes/deprecations/deletions and changes in tools:
>
>    1. Add Adaptive SRTT-based Forwarding strategy (Issue #3566)
>    2. Introduce configurable policy for admission of unsolicited data
>    packets into the content store (Issue #2181).
>    3. Introduce mechanism to update properties (e.g., flags, persistency)
>    of an existing Face (Issue #3731).
>    4. 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)
>    5. ForwarderStatus dataset can now be requested only with
>    /localhost/nfd/status/general interest (Issue #3379)
>    6. Optimizations of tables and forwarding, including reduced usage of
>    shared_ptr (Issue #3205, Issue #3164, Issue #3687)
>    7. Display extended diagnostic information if NFD crashes (Issue #2541)
>    8. Visualize NACK counters in nfd-status output (Issue #3569)
>    9. Extend management to process the new LocalFieldsEnabled attribute
>    when creating/updating Faces (Issue #3731)
>    10. Switch logging facility to use Boost.Log (Issue #3562)
>    11. Refactor implementation of RIB Manager to make it uniform with
>    other managers (Issue #2857)
>    12. Miscellaneous code refactoring (Issue #3738, Issue #3164, Issue
>    #3687, Issue #3205, Issue #3608, Issue #3619, Issue #2181)
>
>
> I wonder what's the major difficulty of integrating NFD 0.5.0 into ndnSIM?
> 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?
>
> Yours, Junxiao
>
> On Sat, Oct 29, 2016 at 12:16 PM, Spyridon (Spyros) Mastorakis <
> mastorakis at cs.ucla.edu> wrote:
>
>> To clarify things:
>>
>> 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.
>>
>> 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.
>>
>> I wish we had more manpower to be able to keep up more actively.
>>
>> Thank you,
>> Spyros
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20161029/a8faaa13/attachment.html>