[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