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

[Ravi Ravindran]

This is a draft we had proposed in the context of CCN a few ICNRGs back,
titled "Support for Notifications in CCN"

https://tools.ietf.org/html/draft-ravi-ccn-notification-00

Regards
Ravi

On Mon, Dec 7, 2015 at 10:08 AM, <Marc.Mosko at parc.com> wrote:

> 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.
>
> Marc
>
> > 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
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20151207/2107b1d6/attachment.html>