Feature #3968
closed
Forward Interest to ad hoc incoming face
Added by Junxiao Shi about 7 years ago. Updated almost 7 years ago.
100%
Description
On an "ad hoc" face (#3967), a received packet is not expected to be received all nodes on the multi-access media, and therefore a node should be able to repeat the packet out of the same face in order to reach more nodes.
When processing an Interest received on an "ad hoc" face, if a FIB nexthop points to the same face, that face should be eligible as a nexthop.
This issue changes AccessStrategy, AsfStrategy, BestRouteStrategy2, and MulticastStrategy to consider this condition.
When processing a Data received on an "ad hoc" face, if a PIT in-record points to the same face, the Data should be send out of the same face.
This issue changes incoming Data pipeline to perform such forwarding.
Updated by Junxiao Shi about 7 years ago
- Blocked by Feature #3967: "ad hoc" property on multi-access face added
Updated by Junxiao Shi about 7 years ago
- Blocked by Feature #3176: NACK in multicast strategy added
Updated by Teng Liang about 7 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
Updated by Teng Liang about 7 years ago
Junxiao Shi wrote:
When processing an Interest received on an "ad hoc" face, if a FIB nexthop points to the same face, that face should be eligible as a nexthop.
This issue changesAccessStrategy,AsfStrategy,BestRouteStrategy2, andMulticastStrategyto consider this condition.
AccessStrategy is designed for the last hop on the NDN testbed, which should not be an "ad hoc" face. The others may be applied to ad hoc networks.
Updated by Junxiao Shi about 7 years ago
- Assignee changed from Teng Liang to Ashlesh Gawande
- % Done changed from 10 to 60
https://gerrit.named-data.net/3802 patchset5 has enhanced test cases using TopologyTester, which is also extended to support ad hoc face creation.
AsfStrategy is crashing in NamespaceInfo::get when Data comes back via an ad hoc face.
I believe this is a bug in AsfStrategy which makes it incompatible with ad hoc faces, since the test is working correctly with other strategies.
This issue is now assigned to Ashlesh, maintainer of AsfStrategy, to investigate this problem.
vagrant@m0212:~/NFD$ gdb --args build/unit-tests-daemon -t 'Fw/TestAdHocForwarding/SingleNexthop<N3nfd2fw3asf11AsfStrategyE>'
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build/unit-tests-daemon...done.
(gdb) catch throw
Catchpoint 1 (throw)
(gdb) run
Starting program: /home/vagrant/NFD/build/unit-tests-daemon -t Fw/TestAdHocForwarding/SingleNexthop\<N3nfd2fw3asf11AsfStrategyE\>
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff22d9700 (LWP 2569)]
[Thread 0x7ffff22d9700 (LWP 2569) exited]
[New Thread 0x7ffff22d9700 (LWP 2570)]
Running 1 test case...
1415684132.005000 TRACE: [AsfStrategy] Looking for best face for /P
1415684132.005000 TRACE: [AsfStrategy] Scheduling timeout for /P FaceId: 256 in 1000 milliseconds ms
1415684132.015000 TRACE: [AsfStrategy] Looking for best face for /P
1415684132.015000 TRACE: [AsfStrategy] Scheduling timeout for /P FaceId: 256 in 1000 milliseconds ms
1415684132.025000 TRACE: [AsfStrategy] Looking for best face for /P
1415684132.025000 TRACE: [AsfStrategy] Scheduling timeout for /P FaceId: 257 in 1000 milliseconds ms
Catchpoint 1 (exception thrown), 0x00007ffff62838b0 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt full
#0 0x00007ffff62838b0 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#1 0x00007ffff62d5447 in std::__throw_out_of_range(char const*) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#2 0x000000000070985b in std::__detail::_Map_base<unsigned long, std::pair<unsigned long const, nfd::fw::asf::FaceInfo>, std::allocator<std::pair<unsigned long const, nfd::fw::asf::FaceInfo> >, std::__detail::_Select1st, std::equal_to<unsigned long>, std::hash<unsigned long>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true>, true>::at (this=this@entry=0xbaafe8, __k=@0x7fffffffcb60: 256)
at /usr/include/c++/4.8/bits/hashtable_policy.h:544
__h = 0xbaafe8
__code = <optimized out>
__n = <optimized out>
__p = <optimized out>
#3 0x0000000000707f39 in at (__k=@0x7fffffffcb60: 256, this=0xbaafe8) at /usr/include/c++/4.8/bits/unordered_map.h:613
No locals.
#4 get (faceId=256, this=0xbaafe0) at ../daemon/fw/asf-measurements.hpp:221
No locals.
#5 nfd::fw::asf::AsfStrategy::beforeSatisfyInterest (this=<optimized out>, pitEntry=std::shared_ptr (count 2, weak 0) 0xbb5228,
inFace=..., data=...) at ../daemon/fw/asf-strategy.cpp:126
namespaceInfo = 0xbaafe0
faceInfo = <optimized out>
#6 0x000000000070fa0a in operator() (strategy=..., __closure=<optimized out>) at ../daemon/fw/forwarder.cpp:363
pitEntry = <optimized out>
inFace = <optimized out>
data = <optimized out>
#7 std::_Function_handler<void(nfd::fw::Strategy&), nfd::Forwarder::onIncomingData(nfd::face::Face&, const ndn::Data&)::__lambda10>::_M_invoke(const std::_Any_data &, nfd::fw::Strategy &) (__functor=..., __args#0=...) at /usr/include/c++/4.8/functional:2071
No locals.
#8 0x0000000000714f26 in std::function<void (nfd::fw::Strategy&)>::operator()(nfd::fw::Strategy&) const (
this=this@entry=0x7fffffffccd0, __args#0=...) at /usr/include/c++/4.8/functional:2471
No locals.
#9 0x0000000000714f47 in nfd::Forwarder::dispatchToStrategy(nfd::pit::Entry&, std::function<void (nfd::fw::Strategy&)>) (
this=this@entry=0xb72bb0, pitEntry=..., trigger=...) at ../daemon/fw/forwarder.hpp:276
No locals.
#10 0x000000000071393e in nfd::Forwarder::onIncomingData (this=0xb72bb0, inFace=..., data=...) at ../daemon/fw/forwarder.cpp:363
__for_range = std::vector of length 1, capacity 1 = {std::shared_ptr (count 2, weak 0) 0xbb5228}
__for_begin = <optimized out>
isViolatingLocalhost = <optimized out>
pitMatches = std::vector of length 1, capacity 1 = {std::shared_ptr (count 2, weak 0) 0xbb5228}
pendingDownstreams = std::set with 0 elements
now = {d_ = {rep_ = 45000000}}
#11 0x000000000071045a in nfd::Forwarder::startProcessData (this=<optimized out>, face=..., data=...)
at ../daemon/fw/forwarder.cpp:100
No locals.
Updated by Ashlesh Gawande about 7 years ago
I think this is what is happening:
Running 1 test case...
face A: 256
face B: 256
face C: 256
---nodeA---
1415684132.005000 TRACE: [AsfStrategy] Looking for best face for /P
forward m_fit faceId: 256
FaceInfoTable has FaceInfo for only faceid 256 in node A
1415684132.005000 TRACE: [AsfMeasurements] Creating face info face: 256
1415684132.005000 TRACE: [AsfStrategy] Scheduling timeout for /P FaceId: 256 in 1000 milliseconds ms
---nodeA---
---nodeB---
1415684132.015000 TRACE: [AsfStrategy] Looking for best face for /P
1415684132.015000 TRACE: [AsfMeasurements] Creating face info face: 256
forward m_fit faceId: 256
1415684132.015000 TRACE: [AsfStrategy] Scheduling timeout for /P FaceId: 256 in 1000 milliseconds ms
---nodeB---
---nodeC---
1415684132.025000 TRACE: [AsfStrategy] Looking for best face for /P
1415684132.025000 TRACE: [AsfMeasurements] Creating face info face: 257 (face of the ndnpingserver)
forward m_fit faceId: 257
1415684132.025000 TRACE: [AsfStrategy] Scheduling timeout for /P FaceId: 257 in 1000 milliseconds ms
beforesatisfy m_fit faceId: 257
1415684132.025000 TRACE: [AsfStrategy] InFace: 257
1415684132.025000 TRACE: [AsfMeasurements] Recording RTT for FaceId: 257 RTT: 0 microseconds SRTT: 0 microseconds
---nodeC---
---nodeB---
beforesatisfy m_fit faceId: 256
1415684132.035000 TRACE: [AsfStrategy] InFace: 256
1415684132.035000 TRACE: [AsfMeasurements] Recording RTT for FaceId: 256 RTT: 20000 microseconds SRTT: 20000 microseconds
---nodeB---
---nodeA---
beforesatisfy m_fit faceId: 257
FaceInfoTable has FaceInfo for only faceid 257 in nodeA - not sure how this happened, should be 256 (investigating this)
1415684132.045000 TRACE: [AsfStrategy] InFace: 256
unknown location(0): fatal error in "SingleNexthop<N3nfd2fw3asf11AsfStrategyE>": std::out_of_range: _Map_base::at
Updated by Ashlesh Gawande about 7 years ago
Okay, above assessment was wrong, it is node C at the very end where beforeSatisfyInterest is called and not node A.
What interest is C trying to satisfy i.e why does C get data from B? Node C has FaceInfo about face 257 before as it forwarded an interest to that face.
Node C does not have FaceInfo about face 256 because it did not forward an interest to it yet so cannot find an entry in the FaceInfoTable.
Running 1 test case...
face A: 256
face B: 256
face C: 256
1415684132.005000 DEBUG: [Forwarder] onIncomingInterest face=257 interest=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.005000 DEBUG: [Forwarder] onContentStoreMiss interest=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.005000 DEBUG: [AsfStrategy] 9384 afterRceiveInterest: 257
1415684132.005000 TRACE: [AsfStrategy] 9384 Looking for best face for /P
1415684132.005000 TRACE: [AsfStrategy] 9384 HopFace: 256
1415684132.005000 TRACE: [AsfStrategy] 9384 FaceInfo does not exist (nullptr)
1415684132.005000 TRACE: [AsfStrategy] 9384 Forwarding interest to face: 256
1415684132.005000 DEBUG: [Forwarder] onOutgoingInterest face=256 interest=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.005000 TRACE: [AsfStrategy] 9384 getOrCreateFaceInfo for face: 256
1415684132.005000 TRACE: [AsfMeasurements] Inserting face into m_fit: 256
1415684132.005000 TRACE: [AsfMeasurements] m_fit faceId: 256
1415684132.005000 TRACE: [AsfStrategy] 9384 m_fit faceId: 256
1415684132.005000 TRACE: [AsfStrategy] Scheduling timeout for /P FaceId: 256 in 1000 milliseconds ms
1415684132.015000 DEBUG: [Forwarder] onIncomingInterest face=256 interest=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.015000 DEBUG: [Forwarder] onContentStoreMiss interest=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.015000 DEBUG: [AsfStrategy] 887 afterRceiveInterest: 256
1415684132.015000 TRACE: [AsfStrategy] 887 Looking for best face for /P
1415684132.015000 TRACE: [AsfStrategy] 887 HopFace: 256
1415684132.015000 TRACE: [AsfStrategy] 887 FaceInfo does not exist (nullptr)
1415684132.015000 TRACE: [AsfStrategy] 887 Forwarding interest to face: 256
1415684132.015000 DEBUG: [Forwarder] onOutgoingInterest face=256 interest=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.015000 TRACE: [AsfStrategy] 887 getOrCreateFaceInfo for face: 256
1415684132.015000 TRACE: [AsfMeasurements] Inserting face into m_fit: 256
1415684132.015000 TRACE: [AsfMeasurements] m_fit faceId: 256
1415684132.015000 TRACE: [AsfStrategy] 887 m_fit faceId: 256
1415684132.015000 TRACE: [AsfStrategy] Scheduling timeout for /P FaceId: 256 in 1000 milliseconds ms
1415684132.025000 DEBUG: [Forwarder] onIncomingInterest face=256 interest=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.025000 DEBUG: [Forwarder] onContentStoreMiss interest=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.025000 DEBUG: [AsfStrategy] 2778 afterRceiveInterest: 256
1415684132.025000 TRACE: [AsfStrategy] 2778 Looking for best face for /P
1415684132.025000 TRACE: [AsfStrategy] 2778 HopFace: 257
1415684132.025000 TRACE: [AsfStrategy] 2778 FaceInfo does not exist (nullptr)
1415684132.025000 TRACE: [AsfStrategy] 2778 Forwarding interest to face: 257
1415684132.025000 DEBUG: [Forwarder] onOutgoingInterest face=257 interest=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.025000 TRACE: [AsfStrategy] 2778 getOrCreateFaceInfo for face: 257
1415684132.025000 TRACE: [AsfMeasurements] Inserting face into m_fit: 257
1415684132.025000 TRACE: [AsfMeasurements] m_fit faceId: 257
1415684132.025000 TRACE: [AsfStrategy] 2778 m_fit faceId: 257
1415684132.025000 TRACE: [AsfStrategy] Scheduling timeout for /P FaceId: 257 in 1000 milliseconds ms
1415684132.025000 DEBUG: [Forwarder] onIncomingInterest face=256 interest=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.025000 DEBUG: [Forwarder] onInterestLoop face=256 interest=/P/%FC%00%05%07%8E%A5%CDQ%00 drop
1415684132.025000 DEBUG: [Forwarder] onIncomingData face=257 data=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.025000 DEBUG: [Forwarder] onIncomingData matching=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.025000 TRACE: [AsfStrategy] 2778 beforeSatisfy m_fit faceId: 257
1415684132.025000 TRACE: [AsfStrategy] 2778 InFace: 257 pitEntry Name: /P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.025000 TRACE: [AsfMeasurements] Recording RTT for FaceId: 257 RTT: 0 microseconds SRTT: 0 microseconds
1415684132.025000 DEBUG: [Forwarder] onOutgoingData face=256 data=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.035000 DEBUG: [Forwarder] onIncomingData face=256 data=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.035000 DEBUG: [Forwarder] onIncomingData matching=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.035000 TRACE: [AsfStrategy] 887 beforeSatisfy m_fit faceId: 256
1415684132.035000 TRACE: [AsfStrategy] 887 InFace: 256 pitEntry Name: /P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.035000 TRACE: [AsfMeasurements] Recording RTT for FaceId: 256 RTT: 20000 microseconds SRTT: 20000 microseconds
1415684132.035000 DEBUG: [Forwarder] onOutgoingData face=256 data=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.045000 DEBUG: [Forwarder] onIncomingData face=256 data=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.045000 DEBUG: [Forwarder] onIncomingData matching=/P/%FC%00%05%07%8E%A5%CDQ%00
1415684132.045000 TRACE: [AsfStrategy] 2778 beforeSatisfy m_fit faceId: 257
1415684132.045000 TRACE: [AsfStrategy] 2778 InFace: 256 pitEntry Name: /P/%FC%00%05%07%8E%A5%CDQ%00
Updated by Junxiao Shi about 7 years ago
What interest is C trying to satisfy i.e why does C get data from B? Node C has FaceInfo about face 257 before as it forwarded an interest to that face.
Node C does not have FaceInfo about face 256 because it did not forward an interest to it yet so cannot find an entry in the FaceInfoTable.
Node C receives the Interest from face256 and forwards it to face257. When Data comes back from face257 it is returned to face256. At that moment, the PIT entry is still there due to the straggler timer.
Node C's face256 is on an ad hoc WiFi channel, and node B decides to repeat the Data so that node A can hear it. Since node C is within node B's transmission range, it also hears the Data.
Since the Data matches the PIT entry, the strategy is informed that a Data matches this recently satisfied PIT entry.
ASF strategy should not have assumed that Data can only come from a face to which an interest has been sent. It is always possible for Data to come from somewhere else.
Also, strategy should not assume its measurements always exist. As stated in NFD devguide strategy - storage section:
Since the strategy choice for a namespace can be changed at runtime, NFD ensures that all strategy-stored items under the transitioning namespace will be destroyed. Therefore, the strategy must be prepared that some entities may not have strategy-stored items
Updated by Junxiao Shi about 7 years ago
- Status changed from In Progress to Resolved
- Assignee changed from Ashlesh Gawande to Teng Liang
Teng should update NFD devguide.
Updated by Teng Liang about 7 years ago
Junxiao Shi wrote:
Teng should update NFD devguide.
I did it several days ago. You can help to review.
Updated by Junxiao Shi about 7 years ago
As of nfd-docs:commit:bc2a286d0e4ddacd1fae69f3234a5b5cb5394ab9, inaccurate statements include but are not limited to:
- best-route strategy: "is forwarded to the lowest-cost nexthop (except downstream"
Updated by Teng Liang almost 7 years ago
The description of the best route strategy is modified to support an ad hoc Face (commit 910c3a4ac6fc90918ca64ac55278276f932d0cfe).
Updated by Junxiao Shi almost 7 years ago
- Status changed from Resolved to Closed
- % Done changed from 60 to 100
I've reviewed devguide and it looks OK.
Updated by Davide Pesavento about 6 years ago
- Has duplicate Feature #4510: Allowing the same packet to come in and go out the same face added