<div dir="ltr">Hi Adhy<br><div><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm working on a wireless scenario (my apologies! I forgot to clarify this in my first email).<br>
- Point 1 (Send the Data to a different interface): nodes will broadcast packets on the same interface (WiFi);<br>
</blockquote>
<br></span>
Maybe you can use a broadcast/multicast face instead?</blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div><div>Wireless networks are broadcast in nature, so it's natural to use a broadcast or ad hoc wireless face.<br></div><div>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.<br></div><div> <span></span><br><span>
</span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-"></span><div>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.</div></div></div></div></blockquote><div><br></div><div>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.<br></div><div>However, this does not work with broadcast or ad hoc wireless faces.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Can NDNLP be used to exchange my rebroadcast data? If so, will I be able to delay Interest and Data packets at each router?</div></div></div></div></blockquote><div><br>Yes, you can define RTS-CTS as part of NDNLP.<br></div><br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">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.</div></blockquote><div><br></div><div>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.<br><br></div><div>Yours, Junxiao <br></div></div></div></div></div></div></div>