<div dir="ltr">Hi Dave<div><br></div><div>NFD has no "pending Interest table". The table is called "Interest table", which contains both pending Interests and recently satisfied Interests (for duplicate suppression and measurements purposes). The abbreviation "PIT" is kept for historical reason.</div><div>All incoming Interests, including those detected as duplicates, and those satisfied from ContentStore, will create an entry in the Interest table.</div><div>Those Interest table entries are useful for duplication suppression, and will be deleted after "straggler timer" expires: 100ms.</div><div><br></div><div>DeadNonceList has expected entry lifetime of 6 seconds. This setting is taken from ccnd 0.8.0.</div><div>Only those with risk of looping will be inserted. "Multi-path arrival" is not looping.</div><div>See spec <<a href="http://redmine.named-data.net/attachments/download/154/dead-nonce-list_20141004.pptx">http://redmine.named-data.net/attachments/download/154/dead-nonce-list_20141004.pptx</a>> for exact condition.<br></div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 1, 2015 at 9:49 AM, Dave Oran (oran) <span dir="ltr"><<a href="mailto:oran@cisco.com" target="_blank">oran@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Given that any Interest arriving after a PIT entry has been satisfied (or timed out) has the hazard of re-creating the PIT and getting processed when it shouldn’t, the “DeadNonceList” entries have to persist for at least the MPL (maximum packet lifetime) of the network. In the IP world, various pathologies can cause this period to be very long; on the order of minutes. What’s the proposed DeadNonce timer for NFD? What’s the worst case memory pressure? - seems like it could be gigantic for a high-speed router. Are there replay attacks that can cause the DeadNonceList to grow without bound?<br>
<br>
Some folks have argued this isn’t an implementation question so much as an architecture question around the use of nonces for loop detection in the first place.<br>
<br>
DaveO.<br>
<div class=""><div class="h5"><br>
> On Mar 1, 2015, at 11:21 AM, Lan Wang (lanwang) <<a href="mailto:lanwang@memphis.edu">lanwang@memphis.edu</a>> wrote:<br>
><br>
> Junxiao,<br>
><br>
> Thank you very much for the explanation and finding the root cause of the problem.  It is causing wild oscillations in the NDNPing delays (switches back and forth between the best path and worse paths back and forth) since the measurements that the strategy is based on were wrong.  I hope this could be fixed as soon as possible since we need the correct results for our paper.<br>
><br>
><br>
> Conceptually the solution requires duplicate suppression (at least for some time) after a PIT entry has been satisfied.  I thought the DeadNonceList was designed for this purpose.  If you check the DeadNonceList before the PIT entry, then you'll detect the duplicate easily.<br>
><br>
> However, if you do not want to check the DeadNonceList first (for whatever reason I don't understand), the current Interest processing flow has a couple issues if I understand correctly:<br>
><br>
> 1. the current logic assume that there's no need to record a dead nonce if the PIT entry is satisfied.  Obviously the example shows that although there's no danger of interest looping, there can be other dangers, e.g., the wrong measurements shown in the example.<br>
><br>
> 2. the in-record and out-record were deleted when the PIT entry is satisfied.  This causes problems since the current logic checks these things before checking the DeadNonceList.<br>
><br>
> So to fix the above, the code needs to (a) record the dead nonce regardless of whether the PIT entry is satisfied and also (b) check the DeadNonceList even after a PIT entry is satisfied.<br>
><br>
> Thanks a lot.<br>
><br>
> Lan<br></div></div></blockquote></div></div></div></div>