[Ndn-interest] NFD Interest Aggregation at Intermediate Router
Stefano Lupo
lupos at tcd.ie
Thu Mar 14 10:24:42 PDT 2019
Hello Junxiao.
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 logs
<https://github.com/stefano-lupo/NFD-Interest-Aggregation-Logs/blob/master/nodeE%20short%20window.log>.
Again both of these interests are seen at the jNDN producer.
I realized I haven't explained my use case very well. These interests
are used as /outstanding sync interests/, 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 *when the position needs to be
updated*. 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 //game/G/pos/<sequence_num> /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.
The ChronoSync paper pretty much sums up what I'd like to accomplish:
/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./
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.
Thanks for your time and the info you have provided!
Regards,
Stefano.
On 14/03/2019 00:36, Junxiao Shi wrote:
> Hi Stefano
>
> In this case, it was ~16 seconds (according to the logs
> <https://github.com/stefano-lupo/NFD-Interest-Aggregation-Logs/blob/master/nodeE_snipped.log#L28-L44>).
> 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.
>
> You should be using the cache rather than aggregation. The producer
> needs to respond as soon as possible.
>
> 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?
>
> 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.
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20190314/5af1ebdb/attachment.html>
More information about the Ndn-interest
mailing list