[Ndn-interest] Delay forwarding in fw strategy

[Adhy Satya]

Hi Professor Wang,

Thank you for your comment.
I tried the Ethernet face before and re-did the tests with three wireless
nodes ( A <---> B <---> C ). I start NFD on all three nodes; register the
ethernet group using "nfdc register / ether://[01:00:5E:00:17:AA]" (I also
made sure mcast is set to yes in the nfd.conf file).
Then I started ndnping server on node C, and ran ndnping from nodes A and
B. I get replies from B <---> C, but timeouts from A <---> B <---> C. In
other words, node B is not relaying the Interest packets.

Do I have to change anything else?
I'm using NFD-0.5.0, ndn-cxx-0.5.0, and ndn-tools-0.4-1-g931dfe8.

Thanks again


On Wed, Jul 26, 2017 at 4:21 PM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

> Isn’t the Ethernet face type in NFD what you are referring to as broadcast
> face?  It supports WiFi interface as well.
>
> Lan
>
> On Jul 24, 2017, at 5:16 PM, Adhy Satya <adhysatya820 at gmail.com> wrote:
>
> Hi there!
>
> Since there're a few topics in this email and I still have some questions,
> I would like to summarize:
>
> - My goal is to delay the forwarding of Interest and Data packets in
> wireless networks.
> - The current NDN implementation has no broadcast face, which would be the
> place to implement those forwarding timers (according to Nick "A
> broadcast face has a small random delay before it sends data in response to
> an interest it receives, and it notices if another node has already
> transmitted the response and therefore should cancel its own transmission
> ")
> - Another option would be making the "beforeSatisfyInterest" mandatory,
> and implement the NFD::Scheduler in both Interest and Data pipelines.
> However, since I'm working with wireless topology, I would still be using a
> unicast face (UDP tunnels in my case).
>
> It seems to me that writing a broadcast face would be the best solution
> and would also extend the capabilities of NDN to wireless scenarios. Did I
> get that right?
> If so, could you point me to the CCNx implementation? I could only find this
>
> <https://git.ustclug.org/lihebi/ndnsim/blob/90076ff370166ccd4a7f0329326d333e65496424/model/ccnx-broadcast-net-device-face.cc>for
> the NS-3 based implementation.
>
>
> Thank you
>
>
> On Tue, Jul 18, 2017 at 4:08 PM, Adhy Satya <adhysatya820 at gmail.com>
> wrote:
>
>> Hi Junxiao,
>>
>> Please find below my comments in blue.
>>
>> Thank you!
>>
>>
>> On Tue, Jul 18, 2017 at 11:27 AM, Junxiao Shi <
>> shijunxiao at email.arizona.edu> wrote:
>>
>>> Hi Adhy
>>>
>>> I'm working on a wireless scenario (my apologies! I forgot to clarify
>>>>>> this in my first email).
>>>>>> - Point 1 (Send the Data to a different interface): nodes will
>>>>>> broadcast packets on the same interface (WiFi);
>>>>>>
>>>>>
>>>>> Maybe you can use a broadcast/multicast face instead?
>>>>
>>>>
>>>> What do you mean by broadcast/multicast face? I'm using UDP tunnels as
>>>> transport method and my strategy is based on the multicast-strategy.
>>>>
>>>
>>> Wireless networks are broadcast in nature, so it's natural to use a
>>> broadcast or ad hoc wireless face.
>>> UDP tunnels are akin to VPN tunnels and they can only handle
>>> point-to-point connectivity. It does not make sense to send a packet
>>> received on a point-to-point face out of the same face because the only
>>> recipient on that face has previously transmitted this packet.
>>>
>>
>> Could you guide me on how to use these faces? To my knowledge, the NFD
>> developer's guide only mention about the broadcast strategy. The transport
>> methods available are TCP, UDP, Ethernet, Websocket, and Unix stream. I
>> also couldn't find anything on ~/NFD/daemon/face
>> Do they need to be developed?
>>
>>
>>>
>>>
>>>>
>>>> My goal is to reduce collisions in the wireless media by making sure
>>>> neighboring nodes don't rebroadcast at the same time. I have an
>>>> implementation on ndnSIM which I used the NS-3 packet tags to accomplish
>>>> this. I want to implement the same functionality in NFD. I wrote a
>>>> consumer/producer application that appends that information, originally in
>>>> the packet tag, in the packet name. The intermediate nodes should be able
>>>> to read the information (but not change it) and rebroadcast accordingly or
>>>> even drop the packet.
>>>>
>>>
>>> For unicast communication on point-to-point faces such as UDP tunnels,
>>> the WLAN card driver can be configured to use RTS-CTS to avoid collisions.
>>> However, this does not work with broadcast or ad hoc wireless faces.
>>>
>>
>> Correct. I'm developing my own collision avoidance technique.
>>
>>
>>>
>>> Can NDNLP be used to exchange my rebroadcast data? If so, will I be able
>>>> to delay Interest and Data packets at each router?
>>>>
>>>
>>> Yes, you can define RTS-CTS as part of NDNLP.
>>>
>>
>>>
>>> I don't know if NDN's implementation kept it, but in the original CCNx
>>>> code the faces that ccnd manages are identified as being
>>>> broadcast/multicast or point-to-point because you have to handle them
>>>> differently... as you seem to be discovering.   A broadcast face has a
>>>> small random delay before it sends data in response to an interest it
>>>> receives, and it notices if another node has already transmitted the
>>>> response and therefore should cancel its own transmission.
>>>>
>>>
>>> This design was rejected at Nov 2016 retreat. Broadcast communication
>>> should be used sparsely only to discover which node is the upstream.
>>> Afterwards, the downstream can unicast Interests to the specific upstream,
>>> and only that upstream would reply.
>>>
>>
>> The scenario you described works well for wired networks. In the case of
>> ad-hoc with mobility (VANETs or MANETs) nodes should be able to rebroadcast
>> even if they are not the original downstream. So there's no broadcast face
>> implemented in NDN?
>>
>>
>>>
>>> Yours, Junxiao
>>>
>>
>>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20170728/40a1a645/attachment.html>