[Nfd-dev] strange results

[Junxiao Shi]

Hi Dave

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.
All incoming Interests, including those detected as duplicates, and those
satisfied from ContentStore, will create an entry in the Interest table.
Those Interest table entries are useful for duplication suppression, and
will be deleted after "straggler timer" expires: 100ms.

DeadNonceList has expected entry lifetime of 6 seconds. This setting is
taken from ccnd 0.8.0.
Only those with risk of looping will be inserted. "Multi-path arrival" is
not looping.
See spec <
http://redmine.named-data.net/attachments/download/154/dead-nonce-list_20141004.pptx>
for exact condition.

Yours, Junxiao

On Sun, Mar 1, 2015 at 9:49 AM, Dave Oran (oran) <oran at cisco.com> wrote:

> 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?
>
> 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.
>
> DaveO.
>
> > On Mar 1, 2015, at 11:21 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
> wrote:
> >
> > Junxiao,
> >
> > 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.
> >
> >
> > 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.
> >
> > 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:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Thanks a lot.
> >
> > Lan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150301/39c0c101/attachment.html>