Re: [6lowapp] HTTP and SIP

["Don Sturek" <[e-mail]>]

Hi Shidan,

 

One more issue:     We have existing smart energy messaging using a
proprietary binary protocol.  We then created an XML structure for these
messages then used W3C EXI to tokenize.  Here is what we ended up with:

Binary Protocol Message Size:    6 Bytes

XML Message Size:  376 Bytes

W3C EXI Tokenized XML Message Size:  12 Bytes.

 

The issue you run into is this:  If you have a data collector model where
many messages are forwarded from leaf nodes up to a central node (like the
ROLL DAG root for example), then you find that the nodes close to the root
have dramatically lower throughput due to congestion from packet forwarding
from the leaf nodes towards the popular data collector device.  We have many
deployments where the IEEE 802.15.4 effective throughput of 140Kpbs turns
into 9Kpbs as you forward towards the data collector.  These deployments are
using a binary protocol where nearly all messages fit into a single packet.
Now, consider what happens where each and every message turns into MANY
packet exchanges.  You will quickly see this does not work..

 

I agree with what Zach wrote in a later note.    I don't want to dissuade
anyone who finds HTTP or SIP working over IEEE 802.15.4 from using it.
However, I think the problem statement in 6LowAPP stands at least for the
smart energy application I am familiar with.

 

Don

 

 

From: Shidan [mailto:[e-mail]] 
Sent: Saturday, October 10, 2009 6:41 PM
To: [e-mail]
Cc: Adam Dunkels; [e-mail]
Subject: Re: [6lowapp] HTTP and SIP

 

Hi Don, I certainly don't disagree with you that we need better latency and
I'm pretty sure Adam doesn't either as he said this is without ANY
optimizations. Given that fact, his statement is quite impressive.

 

The key here is to actually back up any ideas and opinions with real results
and this is what we are in the process of doing.

 

Right now for our purposes, in the Smart Grid domain, we can run SIP, with
some minor changes beyond stack size optimizations, over networks with as
little bandwidth as 80kbps and highly constrained devices. We also
acknowledge for our use cases, latency is not really an issue. 

 

I'm pretty convinced that with the RIGHT sort of optimizations, any latency
issues can be handled without having to dictating general architectural
standards like using REST, SNMP, SIP, etc. which can stifle innovation and
lead to building everything with a hammer. 

 

Having said that Carsten's note is encouraging and I'm pretty convinced this
committee has in mind creating a base that will evolve without stifling
innovation and take real results and proof of concepts of use cases as main
deciding factors. We will definitely be submitting an ID for Hiroshima.

 

--

Shidan Gouran

 

On Sat, Oct 10, 2009 at 8:56 PM, Don Sturek <[e-mail]> wrote:

Hi Adam.
.5 seconds for one hop and 2 seconds for 4 hops are really not acceptable
for many applications.

We should of course investigate using existing protocols.   However it does
not seem likely that full HTTP and XML deployed over devices like IEEE
802.15.4 with very small packet sizes will scale very well  (certainly, for
any application expecting to do home or building controls, those latencies
don't work).  Ideally, we should find something that allows for full
HTTP/etc. while enabling constrained devices to operate with a solution that
can be expanded/compressed.

Don



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Adam Dunkels
Sent: Saturday, October 10, 2009 3:08 PM
To: Shidan
Cc: [e-mail]
Subject: Re: [6lowapp] HTTP and SIP

Shidan wrote:
> "request-response protocols like HTTP may require battery-operated,
> mostly sleeping nodes to be listening for requests much more frequently
> than their application processing requirements alone would need them to
> wake up."
>
> "In addition, some of the applications may require optimizations in
> terms of bandwidth usage; for example, the usual data formats (both
> headers and body) are perceived to be too chatty for the 50-60 byte
> payloads possible in LoWPANs.  Their interpretation and generation may
> require too much code for the 8-bit and 16-bit processors dominating
> LoWPAN nodes."
>
> None of these points seem evident to me.

I very much agree with this. By so quickly dismissing the opportunities
with existing protocols such as HTTP and SIP, this group may miss
reaching widespread adoption of its protocols.

Both these arguments were frequently used in the past against IP for
resource-constrained systems, yet today we take IP for granted for these
systems despite the overheads of IP. We need to a pay price for
interoperability and flexibility, but we think it is worth it.

FWIW, we've recently been working with REST web services
(REST/HTTP/TCP/IP) over 802.15.4 with a low-power duty-cycling radio
protocol (X-MAC) for Contiki. The implementation of the application
layers (REST/HTTP) has roughly a 5kb code footprint. The performance is
not bad: a full HTTP/TCP/IP REST transaction with sensor data in XML
format is completed in roughly 0.5 seconds over a one-hop radio link and
in less than 2 seconds over a four-hop radio network:

http://www.sics.se/~adam/yazar09efficient.pdf

Note that this is without any optimizations at the REST/HTTP/TCP/IP
layers. Full HTTP headers are sent from the curl client, reducing the
overall performance. Full XML is sent from the sensors. Thus there is
plenty of opportunity to improve this without moving away from the
HTTP/TCP/IP framework. For example, as we show in the above paper, there
are significant savings in using conditional HTTP GETs when data have
not changed between subsequent requests.

Like Shidan, I am not saying that we necessarily must use full-fledged
REST/HTTP/TCP/IP or SIP for everything in our resource-constrained
networks. But we mustn't so quickly rule out existing mechanisms just
because of their perceived overhead. Interoperability and flexibility
are very important properties, often more important than bit-level
optimizations.

/adam
--
Adam Dunkels <[e-mail]>se>, [phone]
http://twitter.com/adunk | http://www.sics.se/~adam/

_______________________________________________
6lowapp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowapp