<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hi Junxiao,</div>
<div>Thanks for the quick reply. Comments below.</div>
<div>Jeff</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>><br>
<span style="font-weight:bold">Date: </span>Sun, 18 May 2014 12:20:56 -0700<br>
<span style="font-weight:bold">To: </span>Jeff Burke <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>><br>
<span style="font-weight:bold">Cc: </span>"<<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>>" <<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Nfd-dev] Interest scoping and broadcast channels<br>
</div>
<div><br>
</div>
<p dir="ltr">Hi Jeff</p>
<p dir="ltr">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).</p>
</span>
<div>[jb] That's what I thought and it makes sense to me. (Though, what is the relationship between the
<a href="http://named-data.net/doc/ndn-tlv/interest.html#scope">Scope selector</a> 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.)</div>
<span id="OLK_SRC_BODY_SECTION">
<p dir="ltr">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 <a href="http://redmine.named-data.net/issues/1282">
http://redmine.named-data.net/issues/1282</a></p>
</span>
<div>[jb] They are answering the same prefix with different data objects, so it's a different situation.</div>
<span id="OLK_SRC_BODY_SECTION">
<p dir="ltr">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.</p>
</span>
<div>[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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>[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. </div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<p dir="ltr">Yours, Junxiao</p>
</span>
</body>
</html>