<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><base href="x-msg://2735/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Asit,</div><div><br></div><div>The currently implemented way always attempts to lookup FIB and create PIT entry for incoming interest, and if there is a CS match, such a PIT entry will be immediately satisfied.</div><div><br></div><div>The main reason behind this implementation is to unify metric calculation: for every interest there will always be either new or existing PIT entry, and every satisfied interest can be tracked via PIT entry satisfaction. It is technically possible to change the implementation, but I'm not yet sure if this would get any major benefits.</div><div><br></div><div>As for last question. Yes, it is assumed that there is always some FIB entry, at least a default entry for root prefix, that can match incoming interests. And if there is no such entry, then NDN router is not willing to do anything with such interests.</div><div><br></div><div>Do you have a specific scenario where this assumption doesn't hold? It is relatively easy to create an alternative forwarding strategy with slightly different processing logic.</div><div><br></div><div>---</div><div>Alex</div><br><div><div>On May 8, 2013, at 3:31 PM, Asit Chakraborti <<a href="mailto:Asit.sc.Chakraborti@huawei.com">Asit.sc.Chakraborti@huawei.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-family: Monaco; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Hi Alex,<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">My understanding of the code could be wrong, but it seems we require a FIB match on an incoming<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Interest even before a CS match. Any historical reason behind this ? Or is it just the fact that with<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">the current model and APIs, a FIB entry usually exists if the content is in content store ?<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Thanks,<br>Asit.<o:p></o:p></div></div>_______________________________________________<br>ndnSIM mailing list<br><a href="mailto:ndnSIM@lists.cs.ucla.edu" style="color: purple; text-decoration: underline; ">ndnSIM@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" style="color: purple; text-decoration: underline; ">http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br></div></blockquote></div><br></body></html>