<div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:14px">Hi Alex,</span></div><div><span style="font-family:arial,sans-serif;font-size:14px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:14px">Thanks for your explanation. But I am still curious about why producer node needs to forward interest to NetDevice. Take the following simple topology for example.</span></div>

<span style="font-family:arial,sans-serif;font-size:14px"><div><span style="font-family:arial,sans-serif;font-size:14px"><br></span></div>   (NetDeviceFace)                (NetDeviceFace)</span><br style="font-family:arial,sans-serif;font-size:14px">

<span style="font-family:arial,sans-serif;font-size:14px"> +--------+ /x         +--------------+ /x              +---------------+</span><br style="font-family:arial,sans-serif;font-size:14px">
<span style="font-family:arial,sans-serif;font-size:14px"> | client | ---------- | producerNode | --------------- | someOtherNode |</span><br style="font-family:arial,sans-serif;font-size:14px"><span style="font-family:arial,sans-serif;font-size:14px"> +--------+            +--------------+                 +---------------+</span><div>
<span style="font-family:arial,sans-serif;font-size:14px">                              | /x (AppFace)</span><br style="font-family:arial,sans-serif;font-size:14px"><span style="font-family:arial,sans-serif;font-size:14px">                              |</span><br style="font-family:arial,sans-serif;font-size:14px">
<span style="font-family:arial,sans-serif;font-size:14px">                              |</span><br style="font-family:arial,sans-serif;font-size:14px"><span style="font-family:arial,sans-serif;font-size:14px">                       +-------------+</span><br style="font-family:arial,sans-serif;font-size:14px">
<span style="font-family:arial,sans-serif;font-size:14px">                       | producerApp |</span><br style="font-family:arial,sans-serif;font-size:14px"><span style="font-family:arial,sans-serif;font-size:14px">                       +-------------+</span><font face="arial, sans-serif"><span style="font-size:14px"><br>
</span></font>

<div><span style="font-family:arial,sans-serif;font-size:14px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:14px">If the producerNode received the interest (under the prefix /x), it will send the interest to AppFace (the interest will be satisfied). That is very reasonable. However, does it need to forward the interest to someOtherNode through NetDeviceFace. As you said, </span><span style="font-family:arial,sans-serif;font-size:14px">applications not always can satisfy all interest under specific prefix, but from my observance to the prior experiments (I made some change in </span><font face="arial, sans-serif"><span style="font-size:14px">CustomStrategy::DoPropagateInterest</span></font><span style="font-family:arial,sans-serif;font-size:14px">), producerNode can satisfy each node under /x and send Data packet back to client. Besides, it still have a chance (not every time, just in a small possibility) to forward the interest to someOtherNode. </span><span style="font-family:arial,sans-serif;font-size:14px">Is my observance wrong? Or what is the cause for the producerNode to forward interest (that will be satisfied to AppFace) to someOtherNode?</span></div>
</div><div style><span style="font-family:arial,sans-serif;font-size:14px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:14px">Thanks very much~</span></div><div style><span style="font-family:arial,sans-serif;font-size:14px"><br>
</span></div><div style><span style="font-family:arial,sans-serif;font-size:14px">Regards,</span></div><div style><span style="font-family:arial,sans-serif;font-size:14px">huyao</span></div><div style><span style="font-family:arial,sans-serif;font-size:14px"><br>
</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/4/26 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>Got it. Yes, ID has exactly the same meaning for any face type, regardless of its type.  ndn::L3Protocol knows only about Face abstraction and doesn't care (should it care?) what type of face it.  In the forwarding strategy, you can try to distinguish and prioritize application faces, but it should not be the only option to forward an interest, since applications not always can satisfy all interest under specific prefix.</div>
<div><br></div><div>And another yes, when some interest can be satisfied from the cache, this interest doesn't go beyond ndn::l3Protcol and forwarding strategy, never having any exchange involving application and application face.</div>
<div><br></div><div>---</div><div>Alex</div><div><div class="h5"><div><br></div><div><br></div><div><div>On Apr 25, 2013, at 9:13 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 explanation.</div><div><br></div><div>(1) Saying <span style="font-family:arial,sans-serif;font-size:14px">"AppFace and NetDeviceFace share FaceId", I meant that if I want to write my own forwarding strategy in </span>CustomStrategy::DoPropagateInterest, should I consider AppFace as one usual FaceId like NetDeviceFace? Especially, for a producer node, do I need to intentionally control the incoming interest not to forward towards some other node and meanwhile make it towards AppFace to be satisfied? That seems a little strange though.</div>

<div><br></div><div>(2) Just for a confirmation. Intermediate nodes satisfy interest directly through cache (if possible), not through AppFace? While for producer node, it satisfies interest through AppFace?</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/25 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>What do you mean by "AppFace and NetDeviceFace share FaceId"?  Each face on the node has its own unique id, doesn't matter, NetDeviceFace of AppFace...</div>

<div><br></div><div>Your observation about the current situation with face IDs is exactly right: application faces have IDs that are numerically larger than any other NetDevice face id.  However, this happened completely by "accident" and you should not really rely on it in the forwarding strategy.  If you want to determine if a specific Ptr<Face> is actually an application face, a much safer way is to do a DynamicCast or (better, but I'm not sure yet how it can be implemented) mark application faces somehow in FIB entries:</div>

<div><br></div><div>Ptr<Face> someFace = ...;</div><div><br></div><div>if (DynamicCast<AppFace> (someFace))</div><div>{</div><div>   // someFace is application face</div><div>}</div><div>else</div><div>{</div>

<div>   // someFace is some other type of face</div><div>}</div><div><br></div><div>---</div><div>Alex</div><div><div><br><div><div>On Apr 24, 2013, at 5:24 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 for your explicit explanation. </div><div>Then, for my understanding, it depends on me to decide whether the satisfied interest will be forwarded again towards other nodes (<span style="font-family:arial,sans-serif;font-size:14px">someOtherNode in your example</span>) or not. If I send it to both AppFace and NetDeviceFace which share FaceId, it will do this. And also, from my simple observance from L3RateTracer, if one node connects to two other nodes, face 0 and face 1 is the NetDeviceFace, while face 2 will be the AppFace. Is my understanding right?</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/25 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">Hi!<br>
<br>
1) Yes. There is something like PIT in consumer, but in much more simplistic format.  In consumer it is just a container, containing outstanding sequence number and last retransmission time (m_seqTimeouts variable in apps/ndn-consumer.h).  The code uses boost::multi_index container to have separate indices by sequence number (to efficiently remove) and retransmission time (for retransmission detection).<br>



<br>
2) Let me show you my understanding of your question with slightly different topology<br>
<br>
   (NetDeviceFace)                (NetDeviceFace)<br>
 +--------+ /x         +--------------+ /x              +---------------+<br>
 | client | ---------- | producerNode | --------------- | someOtherNode |<br>
 +--------+            +--------------+                 +---------------+<br>
                              | /x (AppFace)<br>
                              |<br>
                              |<br>
                       +-------------+<br>
                       | producerApp |<br>
                       +-------------+<br>
<br>
Let's say we have three nodes, one is client, one producer, and one is producerNode.  Prefix /x (under which client will be sending interests) is routed:<br>
- on client:  the only NetDeviceFace (towards producerNode)<br>
- on producerNode:  to AppFace (to producer app), to NetDeviceFace (towards someOtherNode)<br>
<br>
When producerNode receives an interests from the client, the strategy may send interest towards application (and this interest will be satisfied) and towards some other node.<br>
<br>
Among the existing strategies, only ns3::ndn::fw::Flooding is doing this, since it is very simple and dumb strategy.  BestRoute and SmartFlooding forward interest only to a "green" face (if available), which implies that they will forward only to the application (ndn::Producer marks the application face "green").<br>



<br>
---<br>
Alex<br>
<div><br>
On Apr 24, 2013, at 8:17 AM, yao hu <<a href="mailto:huyao0107@gmail.com" target="_blank">huyao0107@gmail.com</a>> wrote:<br>
<br>
> Hi Alex,<br>
><br>
> I have two uncertain issues about the behavior of consumer and provider for confirmation.<br>
><br>
> (1) Is there any record like PIT for consumer or requester to memorize past Interest transmission? Possibly for its future retransmission.<br>
><br>
> (2) Say in a tree topology. If the root as the provider has satisfied the incoming Interest to send back its according Data. Is it possible to again forward the Interest to other branches (except the branch for the incoming Interest)? I am asking this because in my forwarding strategy, I saw some traffic in other branches, however I just modified DoPropagateInterest, no other basic ndn functions.<br>



><br>
> Your reply will be really appreciated.<br>
><br>
> Regards,<br>
> huyao<br>
><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>
<br>
</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>
_______________________________________________<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>