<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:Calibri;
        color:windowtext;}
span.msoIns
        {mso-style-type:export-only;
        mso-style-name:"";
        text-decoration:underline;
        color:teal;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">While I agree that ICN can offer a lot of advantages over IP based IoT solutions, I do not think it’s quite so simple to use opportunistic caching as a replacement for something like an
 MQTT broker.  The broker offers several processing features, like the QoS attribute and wildcarding subscriptions.  Using opportunistic caching, consumers can miss publications if the cache gets evicted or maybe just due to adversarial timing of messages.
  <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I looked at the poster, but was not able to determine if there was some mechanism you used beyond opportunistic caching and normal NDN data matching.  I think there are some shortcomings
 to using only those mechanisms in a service that is supposed to deliver (perhaps reliably) all messages in a publication stream to all currently subscribed clients.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Depending on the timing of publications and Interests, a client could miss messages.  For example, a sensor is publishing /sensor/1, /sensor/2, … /sensor/N.  If a consumer is asking for
 these with exclusions and “left most child” to try to walk them in order, it could still miss one due to packet loss.  Lets say it gets 1 … 10, then 11 is lost in network, so 12 is the “left most child” at the closest router.  It would then skip to 12, and
 unless you do some recovery mechanism at the consumer, 11 is lost without even know it.  If one is using timestamps or some other non-monotonic sequence number, then it would be very hard to know about the omission.  Even without packet loss, one could still
 miss messages.  If two consumers are pulling data but at slightly different rates, one could be on “10” and the other pulls “11” and “12” before the next interest from the first arrives.  “12” is now the “left most child” so it would miss 11.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Marc<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">Ndn-interest <ndn-interest-bounces@lists.cs.ucla.edu> on behalf of "Mahmoudi, Charif (IntlAssoc)" <charif.mahmoudi@nist.gov><br>
<b>Date: </b>Monday, May 23, 2016 at 9:06 PM<br>
<b>To: </b>"gabesilva2004@yahoo.com" <gabesilva2004@yahoo.com>, "ndn-interest@lists.cs.ucla.edu" <ndn-interest@lists.cs.ucla.edu><br>
<b>Subject: </b>Re: [Ndn-interest] nfd and iot?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><a href="https://github.com/usnistgov/NamedIoT/files/272882/ndn-poster.pptx"><span style="font-size:11.5pt;font-family:Calibri;color:#954F72">https://github.com/usnistgov/NamedIoT/files/272882</span></a><o:p></o:p></p>
</div>
</body>
</html>