<div dir="ltr">Dear Marc,<div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for this input, my replies are nested below.</div><div class="gmail_extra"><br><div class="gmail_quote">On 17 November 2016 at 11:56, <span dir="ltr"><<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">
Two comments below<div>
<div>
<blockquote type="cite"><span>
<div>On Nov 17, 2016, at 8:09 PM, Seweryn Dynerowicz <<a href="mailto:f80120@ulusofona.pt" target="_blank">f80120@ulusofona.pt</a>> wrote:</div>
<br class="m_-5031361587221302443gmail-m_3513831871767809414gmail-m_4752691966161520810m_288505613945515770Apple-interchange-newline">
</span><div>
<div dir="ltr">Dear Klaus,<br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On 16 November 2016 at 21:51, Klaus Schneider <span dir="ltr">
<<a href="mailto:klaus@cs.arizona.edu" target="_blank">klaus@cs.arizona.edu</a>></span> wrote:
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think Junxiao refers to Section 4.2.8<br>
Interest Finalize Pipeline: "The Dead Nonce List is a global data structure designed to detect looping Interests, and we want to insert as<br>
few Nonces as possible to keep its size down."<br>
</blockquote>
<div><br>
</div>
<div>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</div>
<div>what the next sentence states;</div>
<div><br>
</div>
</span><div>"Only outgoing Nonces (in out-records) need to be inserted, because an incoming Nonce that has never been sent out won't loop back.”</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div></div></div></div></blockquote><div><br></div><div>I agree. From the perspective of the implementation, it seems that the source of the problem you're pointing out is that the Forwarder implements a loop detection scheme which makes assumptions on how the Strategy behave (to make it worse it makes assumptions on how other nodes Strategy behaves). The first case you describe occurs with a Strategy which, for a given Name, forwards EITHER all Interests it receives without changing their Nonce OR none. The second case (aggregation) occurs with a Strategy which decides to only forward some strict subset of the Interests it receives for a given Name. To guarantee that the implemented scheme detects all loops, all the nodes must be using the first Strategy. If any node uses the second Strategy, this introduces the possibility of a non-detectable Interest loop. A more strict scheme for Loop detection (i.e. keep track of traversed nodes) seems to be necessary.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><span><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-5031361587221302443gmail-m_3513831871767809414gmail-m_4752691966161520810m_288505613945515770m_-3049573994958516858gmail-m_4782517304103764552gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So you only compute the RTT for the first Data packet which satisfies<br>
the Interest, right ? If you're only interested in RTT, the OUT-Records<br>
do not enable you<br>
to do anything useful regarding that so they could be removed<br>
straightaway without waiting for STRAGGLER.<br>
</blockquote>
<br>
</span>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).<br>
</blockquote>
<div><br>
</div>
<div>I agree, that would be one reason to have the STRAGGLER timer.</div>
<div><br>
</div>
<div>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 ?</div></div></div></div></blockquote>
</span><div>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.</div>
<div><br>
</div>
<div>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.</div></div></div></div></blockquote><div><br></div><div>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).</div><div><br></div></div><div class="m_-5031361587221302443gmail-m_3513831871767809414gmail-m_4752691966161520810gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-family:monospace,monospace"><br>Best regards,<br><br></span></div><div dir="ltr"><span style="font-family:monospace,monospace">S.<br><br></span><div><span style="font-family:monospace,monospace">+-----------------------------</span><span style="font-family:monospace,monospace"><wbr>-----------------+</span></div><div><span style="font-family:monospace,monospace">| Dynerowicz Seweryn |</span></div><div><span style="font-family:monospace,monospace">| PostDoc Researcher |<br></span></div><div><span style="font-family:monospace,monospace">| SITI, COPELABS, Building U |<br></span></div><div><span style="font-family:monospace,monospace">| Universidade Lusófona |<br></span></div><div><span style="font-family:monospace,monospace">| Campo Grande, 388, 1749-024 Lisboa, Portugal |</span></div><span style="font-family:monospace,monospace">+-----------------------------</span><span style="font-family:monospace,monospace"><wbr>-----------------+</span><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">I hate the empty set; he's so full of himself.</span></div><div><span style="font-family:monospace,monospace"><br>"Judge a man by his questions rather than his answers",<br>Pierre-Marc Gaston, Duc de Lévis<br></span>
<span style="font-family:monospace,monospace"><br>"Ignorance more frequently begets confidence than does knowledge.",<br>C. Darwin<br><br>"Seek freedom and become captive of your desires. Seek discipline<br>and find your liberty.", F. Herbert</span></div><span style="font-family:monospace,monospace"><br></span></div></div></div></div></div></div>
</div></div>