[Ndn-interest] NFD Interest Aggregation at Intermediate Router

[Stefano Lupo]

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; nfdc route add /test/g 
<face_id_of_e>/

/- //On *node**B*: //nfdc face create udp://nodee.com; nfdc route add 
/test/g <face_id_of_e>/

/- //On *nodeE*: ///nfdc face create udp://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/20190313/69a76f1c/attachment.html>