[Ndn-interest] NFD Interest Aggregation at Intermediate Router

[Stefano Lupo]

HI Junxiao.

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!

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.

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?


Thanks for the quick reply!

Stefano.


On 13/03/2019 23:53, Junxiao Shi wrote:
> Hi Stefano
>
> What forwarding strategy are you using on this prefix?
> 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.
>
> Yours, Junxiao
>
>
> On Wed, Mar 13, 2019, 19:46 Stefano Lupo <lupos at tcd.ie 
> <mailto:lupos at tcd.ie>> wrote:
>
>     Hello everyone.
>
>
>     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:
>
>                     ---- B
>
>                 /
>
>     G --- E
>
>                 \
>
>                     ---- A
>
>     In this example, G is the producer of some data under //test/g/, 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 /nfdc/ in the following manner:
>
>     - On *nodeA*: /nfdc face create udp://nodee.com
>     <http://nodee.com>; nfdc route add /test/g <face_id_of_e>/
>
>     /- //On *node**B*: //nfdc face create udp://nodee.com
>     <http://nodee.com>; nfdc route add /test/g <face_id_of_e>/
>
>     /- //On *nodeE*: ///nfdc face create udp://nodeg.com
>     <http://nodeg.com>; nfdc route add /test/g <face_id_of_g>//
>
>     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.
>
>     //
>     //
>
>     Node G also runs NFD and a jNDN app which registers the prefix
>     //test/g /and I can control when to call /face.processEvents()
>     /using a key stroke, so that I can control when things happen.
>
>
>     I then ran this test with NFD's /Forwarder/ and /ContentStore/
>     modules set to a log level of DEBUG so I could see what was going on:
>
>
>     - On *node A*: /ndnpeek /test/g/0 -l 1000000
>     /
>
>     /    - /This expresses an interest for //test/g/0/ with a long
>     timeout for those who might not be familiar
>
>     /    - /This reaches node E who creates a PIT entry and forwards
>     it to node G as expected
>
>         - This then reaches node G who's NFD forwards it on to the
>     jNDN app for handling
>
>             - However the app does *not* respond with the Data or even
>     see the Interest yet, as I will manually call
>     /face.processEvents()/ with a key stroke/later
>     /
>
>     /
>     /
>
>     /- /On *node B*: /ndnpeek /test/g/0 -l 1000000/
>
>         - This again reaches node E
>
>         - Node E does *not* create a *new *PIT entry (or at least the
>     /nPitEntries/ from the output of /nfdc status/ doesn't change),
>     but presumably adds node B's face to the existing entry.
>
>         - *However, node E then forwards a _second_ Interest to G with
>     the same name of //test/g/0/*
>
>     **- This second interest reaches node G's NFD who proceeds to
>     forward the second interest to the jNDN app.
>
>         - This is the behavior I wasn't expecting!
>
>
>     - On *node G*: I finally call /face.processEvents()/
>
>         - Node G then sees the *two* Interests (which have the *exact
>     same name*) and responds to them with the appropriate Data
>
>         - Whichever Data packet reaches node G's NFD first is then
>     forwarded to node E and onto nodes A and B
>
>         - The Data packet that reaches node G's NFD second is then
>     marked as unsolicited and dropped by the NFD
>
>
>     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.
>
>     The logs produced by the NFDs at each of the nodes are available
>     at this repo
>     <https://github.com/stefano-lupo/NFD-Interest-Aggregation-Logs> 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.
>
>
>     Thanks in advance for any information.
>
>     Stefano
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20190314/da5004ac/attachment-0001.html>