[MR #332] local clock module

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[MR #332] local clock module

Ludovic Thomas
Dear ns-3 developers and maintainers,
congratulations for the SIGCOMM award and for the 3.31 release!

I would like to start a discussion on the recent merge request that
Guillermo posted about clocks (merge request #332). Sorry for the timing
(just a few days before the release), it was an unfortunate
synchronization with our internal deadlines. Since the freeze period is
perhaps closing in a few days, we wanted to maybe discuss the possible
options for this work.

The merge request is about bringing the notion of local time to ns-3.
For context, in safety-critical avionic networks, the notion of time is
very important and recent work tends to show that clock nonidealities
can somehow trigger cascade effects that in turn have serious
consequences on the stability of the network. A few months back, as we
wanted to validate our work using simulation, the absence of local
clocks in ns-3 was an obstacle for us. Guillermo has managed to overcome
the issue, so we thought of proposing this part of his work to the ns-3
community.

I know that the local-clock notion in ns-3 has been somehow a pipe dream
over the last years. However, we believe that this new proposal is worth
reviewing since it builds on previous attempts, their ideas and their
limitations. A description of the module is available as a pdf in the
merge request.

To facilitate the integration, we had, from the beginning, the
requirement that the module should operate without requiring any change
in already existing modules, especially not modifying the way they
schedule events through the Simulator::Schedule__() set of functions. My
understanding is that this way of development is the one that you
promote through the idea of ns-3 apps. I actually only figured out about
the ns3 app store a few days back. Our initial idea was to propose the
module in the mainframe code, and we continue to believe this is the
best option, based on below arguments. However, we would gladly get your
thoughts about it and about the proposed code in general.

So in our mind local clocks are very close to the core of the simulator
since they directly affect the way all the other modules are scheduling
events. Hence, the proposed classes are very low-level. We even have an
implementation of ns3::SimulatorImpl, and all the today existing
implementations of ns3::SimulatorImpl are in the 'core' module. At first
we had even considered that the proposed classes could be proposed for
the 'core' module, but we thought it could have been a red flag for you,
which is why we propose them outside of the 'core' module. Also
LocalTimeSimulatorImpl makes use of the event context, so we anticipate
that in the future this could be merged with the other big user of the
context, ns3::DistributedSimulatorImpl (mainframe code). Having the
proposed LocalTimeSimulatorImpl in the mainframe code makes sense for us
in this way.

Also, a major problem in our community is the variety of tools that are
used for time-related issues: many partners want to use ns-3 as a
reference in network simulation, but then they figure out that ns-3 does
not support local clocks - probably by overlooking the tutorial or the
manual - and so they go for various other tools (GNS3, OpenBach, and
many others). As of today it makes the process of comparing results and
methods a significant pain. Ideally, future research teams in our
community would quickly spot that ns-3 supports local clocks, and I
guess it can be spotted faster if it's in the mainframe code, in the
same Doxygen webpage, etc

These are our thoughts about the module, and we'll be happy to discuss!

Best,
Ludovic

Reply | Threaded
Open this post in threaded view
|

Re: [MR #332] local clock module

Tom Henderson-2
On 6/30/20 6:05 AM, Ludovic Thomas wrote:
> Dear ns-3 developers and maintainers,
> congratulations for the SIGCOMM award and for the 3.31 release!
>
> I would like to start a discussion on the recent merge request that
> Guillermo posted about clocks (merge request #332).

Hi Ludovic, thank you for a nice submission. I agree that this feature
would fit most naturally in the core module.  Can others interested in
this capability try to review in the next few days?

- Tom