[Ndn-interest] Delay forwarding in fw strategy

Adhy Satya adhysatya820 at gmail.com
Mon Jul 24 15:16:13 PDT 2017


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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20170724/5a6202d7/attachment.html>


More information about the Ndn-interest mailing list