[Ndn-interest] nfd and iot?

Junxiao Shi shijunxiao at email.arizona.edu
Mon May 23 20:33:25 PDT 2016


Dear folks

I have a little bit of experience playing with both NDN and MQTT on a
temperature sensor.

NDN is a request-response protocol.
The temperature must first register a prefix on the router before it could
receive Interests. This step is quite difficult given the limited
computation power on the sensor. (reply to
http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2016-May/000330.html if you
have a good idea)
After getting past that step, the sensor just needs to respond to Interests.
If we want to continuously collect temperature readings, a separate program
is needed to continuously send Interests to the sensor.

Although NDN allows multiple consumers to send Interests at the same time
and the sensor only needs to process an Interest once, this capability is
limited by the trust model.
To workaround computation power limit, my sensor signs Data packets with
HMAC instead of RSA or ECDSA. Since HMAC uses pre-shared key, I cannot tell
the world what the key is. If I want the world to trust the temperature
readings, my data collection process must re-sign the Data packets with a
RSA/ECDSA key. Therefore, the world would only trust the Data packets from
the data collection process, not from the sensor.

MQTT is a pub-sub protocol over TLS.
Both the sensor and the data collection process connect to a MQTT broker.
The sensor periodically pushes its temperature reading to the broker, which
is then delivered to the data collection process who has subscribed to the
sensor's MQTT topic.

A benefit of MQTT is that it uses less network bandwidth between sensor and
broker. This is especially important if the sensor is connected over a slow
and expensive cellular connection, although this may change when NDN has
header compression.
A drawback of MQTT is that it replies on the sensor to control reporting
frequency, and there isn't an easy way to get "the most current reading"
between two reports (which is easy in NDN by sending another Interest). If
the reports are too frequent, there's more bandwidth overhead and can lead
to congestion; if the reports are too infrequent, subscribers cannot get an
accurate "current" reading.

Finally, in terms of coding efforts, JSON over MQTT is much easier to
program than NDN Interest-Data. But this may change when ndn-cpp-lite
improves.

Yours, Junxiao

On Mon, May 23, 2016 at 4:18 PM, Wentao Shang <wentaoshang at gmail.com> wrote:

> My understanding of MQTT is that it simply specifies the messaging
> interface (wire format and send/receive operations), but does not prescribe
> the implementation detail of the message brokers, which IMHO is the most
> challenging part.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160523/f300a434/attachment.html>


More information about the Ndn-interest mailing list