<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>HI Junxiao.</p>
<p>I had not set a strategy for the prefix on any of the nodes, so I
would imagine it is just the default for each of them? Best route
probably? I am happy to try other strategies!<br>
</p>
<p>In this case, it was ~16 seconds (<a moz-do-not-send="true"
href="https://github.com/stefano-lupo/NFD-Interest-Aggregation-Logs/blob/master/nodeE_snipped.log#L28-L44">according
to the logs</a>). In the actual use case, it would likely be
somewhere between 0-500 ms, but there would be no guarantees.
There would also be some short-lived caching involved which would
cover the case where the data has already been retrieved from G by
the time B is expressing an interest for it.<br>
</p>
<p>I'm not quite sure I follow the reasoning behind the time window.
From E's point of view, does it think the second interest is a
re-expression from the same node since the time between the
Interests was larger than a few ms? That is, it thinks node A is
re-expressing the interest for some reason, even though the
initial interest has not yet exceeded it's lifetime?</p>
<p><br>
</p>
<p>Thanks for the quick reply!</p>
<p>Stefano.<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 13/03/2019 23:53, Junxiao Shi wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOFH+OZ3UdjHQrfiND1zdf7qm=iuBe1b0GGG49Mb0+e_UQDCCw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div>Hi Stefano
<div dir="auto"><br>
</div>
<div dir="auto"><span style="font-family:sans-serif">What
forwarding strategy are you using on this prefix?</span><br>
</div>
<div dir="auto">How much time elapses between A's Interest and
B's Interest arrive at E? If this time is too long, many
strategies may think that the consumer believes the Interest
has been lost, and would thus resend the Interest. The
threshold is usually a few milliseconds.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Yours, Junxiao</div>
<br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Mar 13, 2019,
19:46 Stefano Lupo <<a href="mailto:lupos@tcd.ie"
moz-do-not-send="true">lupos@tcd.ie</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Hello everyone.
<div class="m_6313548662123846992moz-forward-container">
<p><br>
</p>
<p>Sorry in advance if this has been discussed
elsewhere, or if I am overlooking something! I am
currently working on a project using NDN and have
encountered a problem with interests not being
aggregated as I thought they would be. To highlight
the issue consider the following case:</p>
<p> ---- B<br>
</p>
<p> /<br>
</p>
<p>G --- E<br>
</p>
<p> \</p>
<p> ---- A</p>
<p>In this example, G is the producer of some data
under <i>/test/g</i>, A and B are consumers
interested in the data G produces and E is an
intermediate router connecting G to A/B. Each of
these nodes are running in a docker container on the
same machine and I set up the faces and routes
before hand using <i>nfdc</i> in the following
manner:</p>
<p>- On <b>nodeA</b>: <i>nfdc face create udp://<a
href="http://nodee.com" target="_blank"
rel="noreferrer" moz-do-not-send="true">nodee.com</a>;
nfdc route add /test/g <face_id_of_e></i></p>
<p><i>- </i><i>On <b>node</b><b>B</b>: </i><i>nfdc
face create udp://<a href="http://nodee.com"
target="_blank" rel="noreferrer"
moz-do-not-send="true">nodee.com</a>; nfdc route
add /test/g <face_id_of_e></i></p>
<p><i>- </i><i>On <b>nodeE</b>: </i><i><i>nfdc face
create udp://<a href="http://nodeg.com"
target="_blank" rel="noreferrer"
moz-do-not-send="true">nodeg.com</a>; nfdc
route add /test/g <face_id_of_g></i></i></p>
<p>Note I don't make faces / routes in the direction
of the dataflow (i.e. there is no premade face/route
from E --> A) as I don't think they are needed.
Also these host names resolve correctly through the
use of an overlay network in docker. <br>
</p>
<p><i><i><br>
</i></i></p>
<p>Node G also runs NFD and a jNDN app which registers
the prefix <i>/test/g </i>and I can control when
to call <i>face.processEvents() </i>using a key
stroke, so that I can control when things happen. <br>
</p>
<p><br>
</p>
<p>I then ran this test with NFD's <i>Forwarder</i>
and <i>ContentStore</i> modules set to a log level
of DEBUG so I could see what was going on:</p>
<p><br>
</p>
<p>- On <b>node A</b>: <i>ndnpeek /test/g/0 -l
1000000 <br>
</i></p>
<p><i> - </i>This expresses an interest for <i>/test/g/0</i>
with a long timeout for those who might not be
familiar<br>
</p>
<p><i> - </i>This reaches node E who creates a PIT
entry and forwards it to node G as expected</p>
<p> - This then reaches node G who's NFD forwards
it on to the jNDN app for handling</p>
<p> - However the app does <b>not</b> respond
with the Data or even see the Interest yet, as I
will manually call <i>face.processEvents()</i> with
a key stroke<i> later<br>
</i></p>
<p><i><br>
</i></p>
<p><i>- </i>On <b>node B</b>: <i>ndnpeek /test/g/0
-l 1000000</i></p>
<p> - This again reaches node E <br>
</p>
<p> - Node E does <b>not</b> create a <b>new </b>PIT
entry (or at least the <i>nPitEntries</i> from the
output of <i>nfdc status</i> doesn't change), but
presumably adds node B's face to the existing entry.</p>
<p> - <b>However, node E then forwards a <u>second</u>
Interest to G with the same name of <i>/test/g/0</i></b></p>
<p><b> </b>- This second interest reaches node
G's NFD who proceeds to forward the second interest
to the jNDN app.</p>
- This is the behavior I wasn't expecting!<br>
<p><br>
</p>
<p>- On <b>node G</b>: I finally call <i>face.processEvents()</i><br>
</p>
<p> - Node G then sees the <b>two</b> Interests
(which have the <b>exact same name</b>) and
responds to them with the appropriate Data</p>
<p> - Whichever Data packet reaches node G's NFD
first is then forwarded to node E and onto nodes A
and B</p>
<p> - The Data packet that reaches node G's NFD
second is then marked as unsolicited and dropped by
the NFD</p>
<p><br>
</p>
<p>Is this intended behavior or have I set something
up wrong? The packet produced by G is multicasted
back to both A and B through E indicating that the
PIT entries are correct, but it seems odd that the
application level producer at node G must see both
of these interests? For context I am currently
prototyping a small P2P multiplayer game that runs
over NDN, meaning Interest aggregation could save
producers a lot of cycles and network traffic. <br>
</p>
<p>The logs produced by the NFDs at each of the nodes
are available at <a
href="https://github.com/stefano-lupo/NFD-Interest-Aggregation-Logs"
target="_blank" rel="noreferrer"
moz-do-not-send="true">this repo</a> if anyone
would like to take a look - I included copies which
have only (what I think is) the relevant information
and some comments on what happens.</p>
<p><br>
</p>
<p>Thanks in advance for any information.</p>
<p>Stefano<br>
</p>
</div>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</body>
</html>