Re: [6lowapp] HTTP and SIP

[Shidan <[e-mail]>]

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
>
>