Re: [6lowapp] HTTP and SIP

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: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf
Of Adam Dunkels
Sent: Saturday, October 10, 2009 3:08 PM
To: Shidan
Cc: 6lowapp@ietf.org
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 <adam@sics.se>se>, +46707731614
http://twitter.com/adunk | http://www.sics.se/~adam/
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp