[Nfd-dev] Vehicular face design: preliminary questions

[Junxiao Shi]

Hi Davide

1/ targeting v0.3 or v0.4?
The policy is one release every three months.
According to this policy, the release date of v0.3 is projected to be Nov
25, 2014.

2/ submitting supporting components early
Nothing prevents you from submitting supporting components early.
One prior example is RttEstimator
<https://github.com/named-data/NFD/commit/02e32247ac478023c61a0f5d38e973b71f076c75>.
It's intended to be used by forwarding strategies in the future, but no
current strategy uses it. When I submit that component, I'm almost sure
that I won't be able to complete a strategy that needs RttEstimator.

I suggest you to provide a design document that explains how many
components are there, their functionality and relationship.
Without this document, the necessity of components would be challenged, and
you'll have a hard time getting them approved.

3/ platform limitation
Platform policy requires all projects to *build *on both Ubuntu and OSX.
As I understand, if the addition of V2V face and supporting components
doesn't cause a build failure, you're fine.
One prior example is that EthernetFace
<http://redmine.named-data.net/issues/1877#note-13> does not support OSX
with Boost 1.56.

If you intend to support Ubuntu and Boost 1.54 only, I suggest adding a
configuration option, so that V2V face and supporting components are
compiled only if "./waf configure" is executed with "--with-v2v" option.

4/ threading
The decision of not to use threading comes from Van's opinion at 20140115
meeting: context switching is expensive - a context switch costs around 100
instructions.
Threading can be used if you can prove it's more efficient than a design
without threading.

I personally agree that it’s worth seconds of programmer time to save hours
of CPU time <http://www.johndcook.com/blog/2014/08/17/time-exchange-rate/>.
If you can illustrate that a design without threading is much more
difficult to develop than a design with threading, and an implementation
with threading won't become a bottleneck on V2V's typical operation
environment (vehicle onboard computer), I'll agree with using threading.

5i/ NDNLP common superclass
NDNLP component is already implemented individually.
If you think it's effective to make a superclass, please propose its API.

5ii/ duplicate suppression superclass
If you think it's effective to make a superclass, please propose its API.


Yours, Junxiao


On Thu, Aug 21, 2014 at 10:25 AM, Davide Pesavento <davide.pesavento at lip6.fr
> wrote:

> Hi guys,
>
> We recently started designing the vehicular face for NFD (basically an
> ad-hoc wifi face that uses raw 802.11 frames, see #1216 and related
> tasks), and we have some preliminary questions for you, to help us
> plan the design and implementation phases.
>
> 1/ Is there a tentative release schedule for v0.3? Depending on it, we
> can decide whether submitting for v0.3 is feasible or if we should
> target v0.4 instead.
>
> 2/ A big chunk of support code that we will have to write is fairly
> separate and independent from the actual V2V face and Link Adaptation
> Layer, for example the location service, the GPS parser, some utility
> classes to read digital road maps, and so on. These components are
> prerequisites for the vehicular face but can be developed
> independently. Would it be acceptable to submit them early (say for
> v0.3) and have them merged, even if we realize that we're unable to
> finish the face in time for that version?
>
> 3/ Our old implementation used raw AF_PACKET sockets directly and was
> therefore Linux-only. We still have no interest in supporting
> platforms other than Linux (and possibly Android at a later time), so
> we'd like to know if we can keep using raw sockets.
> If there's opposition, we might investigate using libpcap, but this
> doesn't mean we will be testing the code on other platforms such as OS
> X, so it may or may not work.
> Another potential problem is that the V2V face may require boost
> version 1.54, when asio::generic::raw_protocol was introduced.
>
> 4/ Are we allowed to use threading inside the vehicular face? (in our
> old design, each V2V face creates a thread where all the "layer-2.5"
> management operations are performed)
>
> 5/ [not really a question] We identified at least two functionalities
> that can possibly be abstracted and factored out in a common
> superclass:
>     (i) NDNLP fragmentation, shared with EthernetFace;
>     (ii) Duplicate data suppression, shared with EthernetFace and
> MulticastUdpFace (this one might prove difficult because the
> suppression mechanisms that we've developed for V2V are substantially
> more complex).
>
> We are trying to come up with an initial design proposal ASAP,
> hopefully we can discuss it in person at NDNcomm.
>
> Thanks,
> Davide
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140821/64873f16/attachment.html>