search

italovalcy / ndvr

NDN Distance Vector Routing
7 stars 4 forks source link

Be careful when update the FIB to change reachability for a mobile node #2

Open italovalcy opened 4 years ago

italovalcy commented 4 years ago

Suppose a scenario such as:

   A
 /   \
B --- C

Currently, NDVR uses the Incoming Face ID to detect how to reach a particular node for two reasons: 1) to get the certificate; 2) to insert FIB entries later on related to learned name prefix from the routing process. This is implemented in the following commit/lines: https://github.com/italovalcy/ndvr/commit/487c877029b6b0c3c065ce40d02e2dbc0a48097c#diff-7cb0052807d3b8a56a34865ab9a08382R236-R238

However, it's worth to notice that since we are using the default multicast forward strategy, the incoming face can be a result of another node forwarding the interest on behalf of someone else. In other words, we create FIB entries to forward NDVR interest using the multicast strategy for ALL faces; thus, one node can forward ndvr messages from other nodes and then the interest might be received from (i) the direct face or (ii) from the intermediate forwarder face! Not necessarily means the node moved!

Ideally, we should use the forward strategy semantics similar to the localhop prefix (nfd::scope_prefix::LOCALHOP):

The localhop scope limits propagation to no further than the next node.

Interest packets under prefix ndn:/localhop are restricted by these rules:

  • If an Interest is received from a local face, it can be forwarded to a non-local face.
  • If an Interest is received from a non-local face, it cannot be forwarded to a non-local face.
  • In either case the Interest can be forwarded to a local face.
  • PIT entry can be satisfied by Data from any source.

Data packets under prefix ndn:/localhop are unrestricted.

Maybe we need a custom forward strategy

italovalcy commented 4 years ago

Commit 9224e34997750277826544a0034031aad69db271 changed NDVR's naming schema to use LOCALHOP scope prefix and after that we were able to improve the problem of a node forwarding NDVR interests on behalf of other nodes (which are not supposed to happen).

In terms of the protocol overhead (number of interest and data packages transmitted by each node), we reduced from ~24k to ~17k in the ndncomm2020 scenario (10rounds, or 400s, of data generation + 20nodes + RandomWalk + 1328s of simulation time):

  1. Before the change:

    $ fgrep "ndn-cxx.nfd.Forwarder:onOutgoingInterest(): [DEBUG] onOutgoingInterest out=(257,0) interest=/ndvr/ehlo/" results/ndncomm2020.log > /tmp/ndvr-nfd-ehlo-interest
$ fgrep "ndn-cxx.nfd.Forwarder:onOutgoingInterest(): [DEBUG] onOutgoingInterest out=(257,0) interest=/ndvr/dvinfo/" results/ndncomm2020.log > /tmp/ndvr-nfd-dvinfo-interest
$ fgrep "ndn-cxx.nfd.Forwarder:onOutgoingData(): [DEBUG] onOutgoingData out=(257,0) data=/ndvr/dvinfo/" results/ndncomm2020.log > /tmp/ndvr-nfd-dvinfo-data
$ wc -l /tmp/ndvr-nfd-*
3740 /tmp/ndvr-nfd-dvinfo-data
6523 /tmp/ndvr-nfd-dvinfo-interest
14486 /tmp/ndvr-nfd-ehlo-interest
24749 total

  2. After using /localhop scope prefix:

    $ fgrep "ndn-cxx.nfd.Forwarder:onOutgoingInterest(): [DEBUG] onOutgoingInterest out=(257,0) interest=/localhop/ndvr/ehlo/" results/ndncomm2020.log > /tmp/ndvr-nfd-ehlo-interest
$ fgrep "ndn-cxx.nfd.Forwarder:onOutgoingInterest(): [DEBUG] onOutgoingInterest out=(257,0) interest=/localhop/ndvr/dvinfo/" results/ndncomm2020.log > /tmp/ndvr-nfd-dvinfo-interest
$ fgrep "ndn-cxx.nfd.Forwarder:onOutgoingData(): [DEBUG] onOutgoingData out=(257,0) data=/localhop/ndvr/dvinfo/" results/ndncomm2020.log > /tmp/ndvr-nfd-dvinfo-data
$ wc -l /tmp/ndvr-nfd-*
3441 /tmp/ndvr-nfd-dvinfo-data
3255 /tmp/ndvr-nfd-dvinfo-interest
10918 /tmp/ndvr-nfd-ehlo-interest
17614 total

We still have some Data packets (DvInfo data replies) being forwarded on behalf of other nodes (from the CS?):

$ awk '{name="Router"$2; if ($7 !~ name) {print $0} }' /tmp/ndvr-nfd-dvinfo-data | wc -l
404

but this is expected from the LOCALHOP scope prefix and we can actually benefit from it.