<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello Junxiao.</p>
<p>I reran the experiment and this time the interests from node A
and node B arrive at node E (the intermediate router) within 6ms
and still the same interest is forwarded twice upstream to G. Here
is a concise version of the <a
href="https://github.com/stefano-lupo/NFD-Interest-Aggregation-Logs/blob/master/nodeE%20short%20window.log"
target="_blank" rel="noreferrer">logs</a>. Again both of these
interests are seen at the jNDN producer. <br>
</p>
<p>I realized I haven't explained my use case very well. These
interests are used as <i>outstanding sync interests</i>, sort of
like how each node in ChronoSync maintains an outstanding interest
containing the digest. Each node in the game will keep an
outstanding interest for every other node's in game position.
However the data corresponding to these interests will only ever
be produced <b>when the position needs to be updated</b>. For
example, if there are three nodes in the game, A, B and G, along
with E acting as an intermediate router, A and B will maintain
outstanding interests for <i>/game/G/pos/<sequence_num> </i>and
G will only respond to these interests when the game engine
determines that G's updated position should be published. The idea
being that if G hasn't moved, or G's velocity hasn't changed (e.g.
its traveling on a path and its position can be accurately
dead-reckoned) then there is no need to publish the update. Thus
its quite possible that E will see relatively long lived
outstanding interests for G's data from different downstream
faces, and ideally only one of these would ever reach G.</p>
<p><br>
</p>
<p>The ChronoSync paper pretty much sums up what I'd like to
accomplish:</p>
<p><i>When multiple interests for the same data come from the
downstreams, NDN routers create only one PIT entry, remembering
all the interfaces from which the interests came, and forward
out only one interest to the upstream. As shown in Fig. 1, this
process essentially constructs a temporary multicast tree for
each requested data item, along which the data is efficiently
delivered to all requesters.</i></p>
<p><br>
</p>
<p>You also mentioned that this is forwarding strategy dependent, is
there anywhere I could get some more information on how this
should work or what strategies I should be using? Best route
probably makes the most sense in my mind.<br>
</p>
<p><br>
</p>
<p>Thanks for your time and the info you have provided!</p>
<p>Regards,</p>
<p> Stefano.</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 14/03/2019 00:36, Junxiao Shi wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOFH+OaHVz=Rn93XuP2Dvb_6LQg1Gfgg-bpRKXeTcON5HUZfjw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Hi Stefano
<div class="gmail_quote" dir="auto">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>In this case, it was ~16 seconds (<a
href="https://github.com/stefano-lupo/NFD-Interest-Aggregation-Logs/blob/master/nodeE_snipped.log#L28-L44"
target="_blank" rel="noreferrer"
moz-do-not-send="true">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>
</div>
</blockquote>
</div>
<div dir="auto">You should be using the cache rather than
aggregation. The producer needs to respond as soon as
possible.</div>
<div dir="auto"><br>
</div>
<div class="gmail_quote" dir="auto">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p> </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>
</div>
</blockquote>
</div>
<div dir="auto">Yes, E thinks the consumer is retransmitting the
Interest. Even if the Interest comes from a different
downstream peer, it might come from the same consumer via a
different path, so E does not distinguish between downstream
peers.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Yours, Junxiao</div>
<div class="gmail_quote" dir="auto">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> </div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>