[Nfd-dev] On the necessity of the STRAGGLER timer

[Seweryn Dynerowicz]

Dear Klaus,

On 17 November 2016 at 19:02, Klaus Schneider <klaus at cs.arizona.edu> wrote:
>
> A more strict loop detection scheme is to keep the PIT in-records around
> after the initial Interest was satisfied, as done by the straggler timer.
>

I don't think that keeping the IN-Records will allow you to detect more
loops than only keeping the OUT-Records Nonces. That scheme would not be
able to detect the forwarding loops described by Marc in his first comment,
namely if the Nonce of the INT a node A sent out gets aggregated under
another INT at some node B upstream (or node B changes the Nonce) which
THEN loops back. Node A will not be able to relate that INT to any it has
previously received (IN-Record) or sent (OUT-Record).

The fundamental problem is that routers have limited memory, so you have to
> remove the information about previously seen Interests at some point. Any
> loop that takes longer than the router's ability to remember previous
> Interests/nonces cannot be detected that way.
>
> The "Dead Nonce List" is really only a performance optimization: Only
> store nonces, not the whole PIT entry + only store some nonces which seem
> more likely to loop (the ones in out-records). This saves some memory, but
> doesn't solve the fundamental problem that you would need unlimited memory
> for perfect loop detection.


I'm not questioning the function that the Dead Nonce List fulfills. My
original question was why delay the insertion of Nonces from OUT-Records to
the DNL by means of the STRAGGLER timer but I guess that because the
OUT-Records are kept in the PIT entry for data measurements it makes sense
to wait that much before transferring only the Nonces in DNL before
deleting the PIT entry.

I was describing what I understand is the RTT that can be computed under
>> the existing implementation. My original concern here is about how to do
>> Data measurements without the need to keep the OUT-Records longer in the
>> PIT entry. The solution to that should make it easy to implement
>> whatever measurements to whichever granularity someone desires. I think
>> I have a good solution to this but I need to think it through (short
>> answer; put it entirely in the strategy and add a callback to it in the
>> beginning of the onIncomingData pipeline).
>>
>
> How is it possible to do an RTT measurement without the out-record?
> Let's say you send out two Interests and Face A and Face B. The Data
> returns on Face A and you remove the whole PIT entry.
> Now that second Data returns on Face B. How could you know its RTT? You
> just deleted the information about when you sent that Interest.
> Of course, you can store this information inside the strategy and then
> implement what you want in onUnsolicitedData(). But what's the benefit
> compared to just using the out-records?
>

I'm still thinking about this... I don't see yet what measuring the RTT in
NDN means.


Best regards,

S.

+----------------------------------------------+
| Dynerowicz Seweryn                           |
| PostDoc Researcher                           |
| SITI, COPELABS, Building U                   |
| Universidade Lusófona                        |
| Campo Grande, 388, 1749-024 Lisboa, Portugal |
+----------------------------------------------+

I hate the empty set; he's so full of himself.

"Judge a man by his questions rather than his answers",
Pierre-Marc Gaston, Duc de Lévis

"Ignorance more frequently begets confidence than does knowledge.",
C. Darwin

"Seek freedom and become captive of your desires. Seek discipline
and find your liberty.", F. Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20161118/33ade876/attachment.html>