[Ndn-interest] Producer taking initiative to "Push" content to network

Marc.Mosko at parc.com Marc.Mosko at parc.com
Mon Dec 7 10:08:11 PST 2015

One can always pack up small amounts of data inside an Interest.  In the NDN architecture, this is usually done by making a name component with data and possibly signing it.  There’s a tech report on the NDN site about signed interests for doing stage lighting or building control or something like that, though informally the method dates back to the very early days of CCNx.

In the CCNx architecture, it specifically allows for a payload field in an interest along with a name component that identifies the payload (for proper multiplexing of interests with different payloads).  It’s about the same effect as putting payload in the name, but for larger payloads reduces the burden on the PIT or other things that need to process the name.

Whichever method is used, putting data in an Interest has a few problems. 

First, it’s (like all network messages) unreliable so you need to use Data object ACKs.  Also, you don’t know if any two interests would go to the same destinations because forwarding strategy might spread them across instances of the name (unless you have a multicast strategy in which case it would try to go to all) or you know you are working specifically with instance names not anycast names.

Pushing unacknowledged (no Data object) data in Interests will leave junk in the PIT tables.  So, you need to use a very short Interest lifetime if you know there will be no response.  this might run afoul of some congestion control algorithms that will penalize Interest sources with unresponsive Data objects.

If you want the data to go to many subscribers, then this will not scale well if each subscriber is giving its own name.  It would be like sending unicast UDP traffic.  Unless all the subscribers can listen to the same name, you won’t get multicast benefits like this.

Pushing large amounts of data in Interests is not the right thing to do.  It is very slow forwarding (you are doing multiple table lookups for the PIT, CS, and FIB at each hop), there’s no congestion control or flow control or ARQ unless you build your own, and if you use Data object as ACKs you need to make sure your naming and caching policies avoid two pushers using the same name or accepting a Data ACK for one pusher at a second (unintended) pusher.


> On Dec 5, 2015, at 12:52 AM, stewart mackenzie <setori88 at gmail.com> wrote:
> On Sat, Dec 5, 2015 at 4:44 PM, Muhammad Faran <m.faran.majeed at gmail.com> wrote:
>> According to second point, we'll have to explicitly set producer to perform
>> "request for interest" functionality to do pushing of content. Am I right?
> This is how I understand it yup :-) You could also take a look at this
> paper: http://conferences.sigcomm.org/sigcomm/2011/papers/icn/p62.pdf
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

More information about the Ndn-interest mailing list