<div dir="ltr">Thanks for the invitation.<div> <div>My other question is, during flooding (discovery and announcement), is there any specific broadcast suppression technique applied? </div><div>If more than one consumer doing content discovery (interest packet flooding) or more than one producer doing content name prefix announcement (data packet flooding) using blind flooding, it will lead to flooding overhead and probably lead to broadcast storm (<a href="https://en.wikipedia.org/wiki/Broadcast_radiation">https://en.wikipedia.org/wiki/Broadcast_radiation</a>) on the local network. The only control mechanism that i found in the source code and nfd dev guide is interest suppression which are design for different purposes.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 28, 2017 at 8:14 AM, Junxiao Shi <span dir="ltr"><<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi Mahyuddin<br><br></div>Teng (CC'd) is still designing the solution. You may join an upcoming NFD call (see invitation on this mailing list) to discuss.</div><div><br></div>Yours, Junxiao<div><div class="h5"><br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 27, 2017 at 8:56 AM, Mahyuddin Husairi <span dir="ltr"><<a href="mailto:mahyuddin@gmail.com" target="_blank">mahyuddin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If the suggested feature on issue <a href="https://redmine.named-data.net/issues/4283" target="_blank">#4283</a> is not accepted, what is the way that self learning strategy switch the forwarding mode from multicast to unicast after discovery? <div>We just assume the relevant unicast face exist? and if not exist how?</div></div><div class="gmail_extra"><div><div class="m_-1625159325828032327h5"><br><div class="gmail_quote">On Mon, Nov 27, 2017 at 9:11 PM, Junxiao Shi <span dir="ltr"><<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Mahyuddin<div class="gmail_extra"><br><div class="gmail_quote"><span><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><span style="font-size:12.8px">I need your opinion about enabling forwarding strategy to create face. At least unicast face (raw ethernet or udp) for dynamic unicast face features in my NDN based MANET solution.</span></div></div></blockquote><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><br></div><div><div style="font-size:12.8px"><span style="font-size:12.8px">1. What is the possible dirty hack way to enable it?</span></div></div></div></blockquote></span><div>Do not look for or use "dirty hack way". The harm of doing so is described on <a href="https://yoursunny.com/t/2017/academic-papers/" target="_blank">https://yoursunny.com/t/201<wbr>7/academic-papers/</a> "program quality" section.<br></div><span><div><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><div style="font-size:12.8px"><span style="font-size:12.8px">AFAIK, to create face, it is part of NFD management protocol API. Is that possible to access that API just like face-module.cpp in NFD tools?</span></div></div></div></blockquote></span><div>No, because forwarding plane is not an application. It cannot send packets to itself.</div><span><div><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 style="font-size:12.8px"><span style="font-size:12.8px">2. Or is there any better way to implement it?</span></div></div></blockquote></span><div><div>The better way is to avoid the program in the first place.</div><div>A face is a generalization of an interface. Therefore, an Ethernet face shall support both multicast and unicast on the same physical interface. NFD currently implements Ethernet unicast like tunnel, which is wrong.</div></div><div>You may achieve unicasting by implementing <a href="https://redmine.named-data.net/issues/4283" target="_blank">https://redmine.n<wbr>amed-data.net/issues/4283</a> . I heard from last NFD call that NFD team is planning to reject this issue, but I believe this is the right way to go. </div><div><br></div><div>Yours, Junxiao</div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span>-- <br><div class="m_-1625159325828032327m_-6963253180538049132gmail_signature" data-smartmail="gmail_signature">Human knowledge Belongs to The World</div>
</span></div>
</blockquote></div><br></div></div></div></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Human knowledge Belongs to The World</div>
</div>