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

[Marc.Mosko at parc.com]

Two comments below

On Nov 17, 2016, at 8:09 PM, Seweryn Dynerowicz <f80120 at ulusofona.pt<mailto:f80120 at ulusofona.pt>> wrote:

Dear Klaus,

On 16 November 2016 at 21:51, Klaus Schneider <klaus at cs.arizona.edu<mailto:klaus at cs.arizona.edu>> wrote:
I think Junxiao refers to Section 4.2.8
Interest Finalize Pipeline: "The Dead Nonce List is a global data structure designed to detect looping Interests, and we want to insert as
few Nonces as possible to keep its size down."

The way I understand this specific point is that we do not want to insert the Nonce for every single Interest we ever receive. This is precisely
what the next sentence states;

"Only outgoing Nonces (in out-records) need to be inserted, because an incoming Nonce that has never been sent out won't loop back.”

This is incorrect, or at best it’s a limited definition of loop.  You could have a first Interest with nonce A that would, if nothing else happened, form a cycle and need to be dropped.  however, at another node, that first Interest could be aggregated with a second Interest with nonce B, and it is that second Interest that loops.   Then B might get aggregated with the node that sent A in the first place, and neither loop is detected because there was no duplicate nonces, only aggregations that will eventually timeout.  One could ask, did a loop really happen in that case?  I think if you are forming an equivalency class on Interests based on aggregation similarity, then yes a loop did happen.

[snip]

So you only compute the RTT for the first Data packet which satisfies
the Interest, right ? If you're only interested in RTT, the OUT-Records
do not enable you
to do anything useful regarding that so they could be removed
straightaway without waiting for STRAGGLER.

I don't know about the specifics, but in principle the straggler timer should help you to do measurements of more then the fastest interface. Whenever you send out Interests on multiple faces (either in parallel or sequential) it can be useful to wait a little longer for responses (Data or NACKs).

I agree, that would be one reason to have the STRAGGLER timer.

But as the RTT is a measure of how fast the last Interest up a certain path was satisfied, wouldn't it make more sense to use the FIB to keep track of the RTT ?

I disagree with this last statement too.  There is nothing in a response that identifies which request triggered the response.  If a forwarder has sent two Interests upstream on the same path you don’t know if you are measuring the time from the 1st interest to the response (a long time) or the time from the 2nd interest to the response (a shorter time).  Because you have replaced the out record, I think you will only measure the shorter time, which could be incorrect.

Personally, I think measuring response time at the granularity of the FIB (which I believe is what these come down to) is not a principled thing to do.  A producer may be serving multiple classes of traffic under one FIB entry, such as very quick static content and very slow dynamically generated content.  In that example, there is really a bi-modal RTT distribution and if you average them you will have an RTT estimate that is wrong for both classes of traffic.  If one were to measure 2nd order statistics, perhaps one could get a 2-sigma or 3-sigma interval, but I’m not sure that’s really useful for anything at a forwarder.

Marc


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20161117/c738cf2d/attachment-0001.html>