[Ndn-interest] Delay forwarding in fw strategy

[Junxiao Shi]

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.


>
> 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.

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.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20170718/994e5cff/attachment-0001.html>