[Ndn-interest] Delay forwarding in fw strategy

Adhy Satya adhysatya820 at gmail.com
Tue Jul 18 13:08:12 PDT 2017

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>

> 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/20170718/dfbe2e18/attachment.html>

More information about the Ndn-interest mailing list