<div dir="ltr">Hi Alex,<div><br></div><div style>Thanks for your explanation. It seems it works. Then, I have a further question about "retry". Assume there is a simple topology as follows.</div><div style><br></div>
<div style>consumer---router---provider0 /x</div><div style> |</div><div style> |</div><div style> provider1 /x</div><div style><br></div><div style>In router, there are two FIB entries which point to face0 (provider0) and face1 (provider1) respectively. But in my forwarding strategy, router always forwards interest to face0 (provider0). The consumer sends 10 interests per second. At some time, I let the link between router and provider0 down (link failure). Then the consumer retransmits the interest because it does not receive the data. It was expected that </div>
<div style><br></div><div style>1) router discards the retransmitted interest before the retry timer expires</div><div style>2) consumer retransmit the interest again because it still does not receive the data</div><div style>
3) finally router will retry face1 (to provider1) to retrieve data after the retry timer expires ?</div><div style><br></div><div style>However actually, I just saw few interests forwarded from router to provider1. In my rate-trace file, I just saw only one data from 30 issued interests for consumer.</div>
<div style><br></div><div style>I think the router still tried to send retransmitted interest to provider0 even after link failure happened. Am I right? If not, what is wrong with my understanding?</div><div style><br></div>
<div style>Thanks a lot!!</div><div style><br></div><div style>Regards,</div><div style>huyao</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/3 Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi huyao,</div><div><br></div><div>Yes, the current ndnSIM is implementing exactly what was mentioned in the paper: when a consumer retransmits an interest, there should be an outstanding PIT entry (if it has expired, then the router has no way to know that the interest has actually been retransmitted), and the router tries to send out interest somewhere else, besides the original face.</div>
<div><br></div><div>Yes, you definitely can control where to send out an interest in the forwarding strategy. It is just not exactly obvious. Ultimately, DoPropagateInterest function has full control over what is happening to the interest. Implementations in BestRoute/Flooding strategies use a couple of helper methods to "skip" already tried faces, but you don't need to use them. Just a brief overview what is happening to the interest in DoPropagateInterest (based on BestRoute).</div>
<div><br></div><div>-> ForwardingStrategy::TrySendOutInterest</div><div> -> ForwardingStrategy::CanSendOutInterest</div><div> -> NO if face == incoming (don't send interest back)</div><div> -> if # of outgoing > 0 (= have previously forwarded this interest)</div>
<div> -> YES if haven't tried yet (this is what essentially <span style="line-height:17.99715805053711px;color:rgb(51,51,51);font-size:11.818181991577148px;white-space:pre-wrap;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px;border:0px;padding:0px">outgoing</span><span style="line-height:17.99715805053711px;color:rgb(51,51,51);font-size:11.818181991577148px;white-space:pre-wrap;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px;font-weight:bold;border:0px;padding:0px">-></span><span style="line-height:17.99715805053711px;color:rgb(51,51,51);font-size:11.818181991577148px;white-space:pre-wrap;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px;border:0px;padding:0px">m_retxCount</span><span style="line-height:17.99715805053711px;color:rgb(51,51,51);font-size:11.818181991577148px;white-space:pre-wrap;font-family:Consolas,'Liberation Mono',Courier,monospace"> </span><span style="line-height:17.99715805053711px;color:rgb(51,51,51);font-size:11.818181991577148px;white-space:pre-wrap;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px;font-weight:bold;border:0px;padding:0px">>=</span><span style="line-height:17.99715805053711px;color:rgb(51,51,51);font-size:11.818181991577148px;white-space:pre-wrap;font-family:Consolas,'Liberation Mono',Courier,monospace"> </span><span style="line-height:17.99715805053711px;color:rgb(51,51,51);font-size:11.818181991577148px;white-space:pre-wrap;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px;border:0px;padding:0px">pitEntry</span><span style="line-height:17.99715805053711px;color:rgb(51,51,51);font-size:11.818181991577148px;white-space:pre-wrap;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px;font-weight:bold;border:0px;padding:0px">-></span><span style="line-height:17.99715805053711px;color:rgb(51,51,51);font-size:11.818181991577148px;white-space:pre-wrap;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px;border:0px;padding:0px">GetMaxRetxCount</span><span style="line-height:17.99715805053711px;color:rgb(51,51,51);font-size:11.818181991577148px;white-space:pre-wrap;font-family:Consolas,'Liberation Mono',Courier,monospace"> </span><span style="line-height:17.99715805053711px;color:rgb(51,51,51);font-size:11.818181991577148px;white-space:pre-wrap;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px;border:0px;padding:0px">()</span> condition is for)</div>
<div> -> NO (face will be skipped)</div><div> -> YES otherwise</div><div><br></div><div>---</div><div>Alex</div><div><div class="h5"><div><br></div><div><div>On May 2, 2013, at 6:27 PM, yao hu <<a href="mailto:huyao0107@gmail.com" target="_blank">huyao0107@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">Hi Alex,<div><br></div><div>Thanks very much! Just a little confusion about what you said.. :(</div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:14px">>>...the consumer just retransmits the interest with the same name and different nonce.</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:14px">I remembered in one of your papers ("</span><font face="arial, sans-serif"><span style="font-size:14px">A Case for Stateful Forwarding Plane"</span></font><span style="font-family:arial,sans-serif;font-size:14px">) which says "</span><font face="arial, sans-serif"><span style="font-size:14px">an Interest retransmitted by the consumer that </span></font><span style="font-size:14px;font-family:arial,sans-serif">may need to be forwarded using a different outgoing interface". Then in the current ndnsim, for consumer, the retransmitted interest is sent on different faces? Could I control that way or select the "different outgoing interface" in forwarding stategy? (As you said, this should be also not the consumer application)</span></div>
<div><span style="font-size:14px;font-family:arial,sans-serif"><br></span></div><div><font face="arial, sans-serif"><span style="font-size:14px">Thanks a lot!!</span></font></div><div><font face="arial, sans-serif"><span style="font-size:14px"><br>
</span></font></div><div><font face="arial, sans-serif"><span style="font-size:14px">Regards,</span></font></div><div><font face="arial, sans-serif"><span style="font-size:14px">huyao</span></font></div><div>
<font face="arial, sans-serif"><span style="font-size:14px"><br></span></font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/3 Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi huyao,</div><div><br></div><div>Consumer retransmission timeout is not the same thing as PIT entry lifetime. I tend to think that it should be shorter. This way, when consumer retransmits, there is PIT entry (= memory about previous interest) and router may make a decision (and has ground to make this decision) to forward the retransmitted interest on some other available face.</div>
<div><br></div><div>What I'm going to say next applies to the implemented strategies in ndnSIM and does not exactly apply to the strategy implemented in ccnx code.</div><div><br></div><div>The consumer/end host is responsible to retransmit an interest if it feels that the data have not came back in time. There is no notion of faces or interfaces, the consumer just retransmits the interest with the same name and different nonce.</div>
<div><br></div><div>Intermediate nodes/routers receiving an interest in some cases can detect that the interest has been retransmitted by the consumer (this implies that there is an unexpired PIT entry). When it is detected, the router may chose different face to forward the interest to.</div>
<div><br></div><div>As I said earlier, consumer application has no idea (and I don't believe it should have any idea) about faces/interfaces available on the computer. The application knows only how to express interest and how to handle data. How exactly the interest is forwarded and to where it is forwarded, this should be a sole responsibility of the underlying NDN stack, not the application.</div>
<div><br></div><div>I hope I didn't confuse you even more :)</div><div><br></div><div>---</div><div>Alex</div><div><div><div><br></div><br><div><div>On May 2, 2013, at 5:10 AM, yao hu <<a href="mailto:huyao@goto.info.waseda.ac.jp" target="_blank">huyao@goto.info.waseda.ac.jp</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">I am sorry to append some words.. When link failure or network congestion happens, <div><br></div><div>1) end host or consumer is responsible to retransmit the interest on other alternative interfaces</div>
<div>
2) intermediate node retries the retransmitted interest to other alternative interfaces</div><div><br></div><div>So is there any strategy difference between 1) and 2) ? what part of functions or methods shows that retransmission or retry stategies?</div>
<div><br></div><div>Thanks a lot again!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/2 yao hu <span dir="ltr"><<a href="mailto:huyao0107@gmail.com" target="_blank">huyao0107@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Alex,<div><br></div><div>Thanks a lot. I am looking into the related code but I am not sure if it also applies to requester? Because there is no PIT entry to check for a requester or consumer. What to do to change or control the requester behavior when retransmitting the interest?</div>
<div><br></div><div>Regards,</div><div>huyao</div></div><div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/2 Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi huyao,<div><br></div><div>Not really. An application has basically no control on how exactly and to where its interests are getting forwarded.</div>
<div>Moreover, an application does not know (and should not know) anything about other faces of an NDN router.</div><div><br></div><div>Actually, there is already some code (this is part of the forwarding strategy) that attempts to use different faces if interest is retransmitted. If an NDN router receives an interests for which there is an outstanding PIT entry, and this interest is coming from the face from which the router has already received an interest (with different nonce), such an interest is considered a retransmission and there is an attempt to forward the interest somewhere else.</div>
<div><br></div><div>ndn::ForwardingStrategy::DetectRetransmittedInterest method defines the retransmission detection logic.</div><div>ndn::ForwardingStrategy::CanSendOutInterest performing some checking to determine whether an interest should be forwarded on the face or not, considering possible retransmission (this call is used in DoPropagateInterst by the implemented forwarding strategies).</div>
<div><br></div><div>---</div><div>Alex</div><div><br><div><div>On May 1, 2013, at 8:22 AM, yao hu <<a href="mailto:huyao0107@gmail.com" target="_blank">huyao0107@gmail.com</a>> wrote:</div><br><blockquote type="cite">
<div dir="ltr">Hi Alex,<div><br></div><div>Thanks for your answer. I am sorry there is one more question after this. </div><div>How to re-send timed out interest to all faces, not retransmit it to the same face again? Do I have to write my own "customConsumer", and do the following </div>
<div>ndn::AppHelper consumerHelper ("customConsumer");</div><div>ApplicationContainer consumer = consumerHelper.Install (node);</div><div><br></div><div>Am I right? Thanks a lot~</div><div><br>
</div><div>Regards,</div><div>huyao</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/4/29 Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi huyao,</div><div><br></div><div>Actually, each retransmitted Interest by ndn::Consumer* application gets its own "unique" (random) nonce.</div>
<div><br></div><div>Consumer::CheckRetxTimeout method (<a href="https://github.com/NDN-Routing/ndnSIM/blob/master/apps/ndn-consumer.cc#L122" target="_blank">https://github.com/NDN-Routing/ndnSIM/blob/master/apps/ndn-consumer.cc#L122</a>) is responsible for detecting and scheduling retransmission of Interest.</div>
<div><br></div><div>---</div><div>Alex</div><div><br><div><div>On Apr 28, 2013, at 7:12 PM, yao hu <<a href="mailto:huyao0107@gmail.com" target="_blank">huyao0107@gmail.com</a>> wrote:</div><br><blockquote type="cite">
<div dir="ltr">Hi Alex,<div><br></div><div>Thanks for your reply. I see. </div><div><br></div><div>One more question is about interest time out or retransmission. Is there a method or function to deal with Interest retransmission or retransmission queue in ndnsim? How about adding a new value to the nonce field in retransmission Interest packet to differentiate it from the orginal one?</div>
<div><br></div><div>I assume that by default the original Interest and the retransmission Interest if timeout happens should be the same format, right?</div><div><br></div><div>Thanks a lot ~</div>
<div><br></div><div>Regards,</div><div>huyao</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/4/29 Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi huyao,</div><div><br></div><div>(1) The application is fully responsible to put the nonce into the interests. ndn::Consumer-based applications put nonce from uniform distribution (<a href="https://github.com/NDN-Routing/ndnSIM/blob/master/apps/ndn-consumer.cc#L206" target="_blank">https://github.com/NDN-Routing/ndnSIM/blob/master/apps/ndn-consumer.cc#L206</a>)</div>
<div><br></div><div>(2) There is GetNonce() method for ndn::Interest class</div><div><br></div><div>(3) If you write your own app, you just set nonce using SetNonce method. If you want to reuse existing consumers, then you probably need to change their implementation to some extent.</div>
<div><br></div><div>---</div><div>Alex</div><br><div><div><div><div>On Apr 28, 2013, at 7:06 AM, yao hu <<a href="mailto:huyao0107@gmail.com" target="_blank">huyao0107@gmail.com</a>> wrote:</div><br></div>
</div><blockquote type="cite"><div><div dir="ltr">Hi Alex,<div><br></div><div>ndnsim documents says nonce field is filled with a value of <span style="font-size:12px;line-height:14px">uint32_t type. Could you please tell </span></div>
<div><span style="font-size:12px;line-height:14px"><br></span></div><div><span style="font-size:12px;line-height:14px">(1) what value is filled in nonce field in the current Interest packet implementation. </span></div>
<div><span style="font-size:12px;line-height:14px"><br></span></div><div><span style="font-size:12px;line-height:14px">(2) how to get the nonce value when receiving Interest packet?</span></div>
<div><span style="font-size:12px;line-height:14px"><br></span></div><div><span style="font-size:12px;line-height:14px">(3) is it possible to fill a self-defined value into nonce field?</span></div>
<div><span style="font-size:12px;line-height:14px"><br></span></div><div><span style="font-size:12px;line-height:14px">Thanks very much!</span></div><div><span style="font-size:12px;line-height:14px"><br>
</span></div><div><span style="font-size:12px;line-height:14px">Regards,</span></div><div><span style="font-size:12px;line-height:14px">huyao</span></div></div></div>
_______________________________________________<br>ndnSIM mailing list<br><a href="mailto:ndnSIM@lists.cs.ucla.edu" target="_blank">ndnSIM@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br>
</blockquote></div><br></div></blockquote></div><br></div>
_______________________________________________<br>ndnSIM mailing list<br><a href="mailto:ndnSIM@lists.cs.ucla.edu" target="_blank">ndnSIM@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br>
</blockquote></div><br></div></div></blockquote></div><br></div>
_______________________________________________<br>ndnSIM mailing list<br><a href="mailto:ndnSIM@lists.cs.ucla.edu" target="_blank">ndnSIM@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br>
</blockquote></div><br></div></div></blockquote></div><br></div>
</div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>**************************************************</div><div>早稲田大学 基幹理工学研究科 情報理工学専攻</div><div>後藤滋樹研究室<br></div><div>胡 曜 (HU Yao)</div><div>E-mail : <a href="mailto:huyao@goto.info.waseda.ac.jp" target="_blank">huyao@goto.info.waseda.ac.jp</a></div>
<div>**************************************************</div>
</div>
_______________________________________________<br>ndnSIM mailing list<br><a href="mailto:ndnSIM@lists.cs.ucla.edu" target="_blank">ndnSIM@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br>
</blockquote></div><br></div></div></div></blockquote></div><br></div>
_______________________________________________<br>ndnSIM mailing list<br><a href="mailto:ndnSIM@lists.cs.ucla.edu" target="_blank">ndnSIM@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br>
</blockquote></div><br></div></div></div></blockquote></div><br></div>