[Ndn-interest] NFD Interest Aggregation at Intermediate Router

Junxiao Shi shijunxiao at email.arizona.edu
Wed Mar 13 16:53:30 PDT 2019


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> 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 nodeB: **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/20190313/278e821c/attachment.html>


More information about the Ndn-interest mailing list