[Nfd-dev] Interest scoping and broadcast channels

[Burke, Jeff]

Hi Junxiao,
Thanks for the quick reply. Comments below.
Jeff


From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Sun, 18 May 2014 12:20:56 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest scoping and broadcast channels


Hi Jeff

A locally-scoped Interest (with prefix ndn:/localhost) can never be satisfied by a Data from a non-local face, because such Data would begin with ndn:/localhost which could not be transmitted on a non-local face (and will be dropped if received).

[jb] That's what I thought and it makes sense to me.  (Though, what is the relationship between the Scope selector<http://named-data.net/doc/ndn-tlv/interest.html#scope> in the TLV packet format and these names?  Couldn't one have the scope selector set without the corresponding name? Apologies if this is explained somewhere already – a link may be needed to that explanation in the TLV packet format doc.)

Multicast face has duplicate suppression capability. If both this host and other hosts are answering with exactly same Data Name, and this host doesn't care about the content from other host, this scenario can be well handled by duplicate suppression. See Task 1282 for discussion on this feature http://redmine.named-data.net/issues/1282

[jb] They are answering the same prefix with different data objects, so it's a different situation.

If this host needs to know the content from other host, use NFD's packet capture feature. The packet capture feature allows a program to listen for a subset of packets processed by NFD, with filters on face, direction, and name prefix. There is no Task for this feature yet.

[jb] Ok, we'll keep an eye out for this.  While I figured that something like this was possible, I had previously come to the conclusion that it was better to preserve NDN semantics – if it is Data that an application is interested in, wouldn't it be most NDN-like if it issued an Interest for it?     This sort of "parasitic Interest", which "listens" on a Face for data but doesn't propagate, seems useful in a variety of contexts having to do with low-bandwidth broadcast channels or power-constrained consumers.    The advantage is that the callback mechanism is exactly the same as what app developers would be used to, without having to descend into a different (packet capture) API.

You may also use the workaround designed by NLSR: express the Interest as soon as you receive it. Strategy won't transmit it into the multicast face.

[jb] Ok, makes sense. But this assumes that you hear the Interest and that it matches your request, right?   There are at least two cases where this isn't a good fit:  1) A lossy radio channel where you hear data from a nearby node more often than interests from a remote consumer closer to the other node ;  2) Let's say the parasitic consumer is interested in /home/devices/sensors but the external interest that generates data is /home/devices/sensors/foo or /home/devices... while it's doable, handling the matching logic in the application seems unnecessarily complicated instead of a passive or parasitic listening capability offered by the library and/or forwarder.




Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140518/32965c30/attachment.html>