Re: [6lowapp] HTTP and SIP

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

On Sat, 10 Oct 2009 21:40:41 -0400, Shidan <[e-mail]> wrote: 
> 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.

I think there is confusion about the word REST in the charter. This 
is only meant to mean that if you want to proxy with HTTP and support 
the design of web-services reusing existing techniques - then we need to 
support GET, PUT, POST, DELETE methods. Maybe it is better to 
remove the word REST if that implies anything more than that to people? 

The purpose of the application protocol work item description was exactly
to 
say that we are not limiting ourselves to one single paradigm. Instead we 
need to integrate features from suitable protocols that allows us to 
innovate yet at the same time easily proxy into HTTP, SIP and SNMP.

My view is: 

- For applications where full HTTP, SIP, SNMP etc. 
can be used - then you are lucky - and you don't necessarily need this 
working group. If you just need to optimize one of the above, then 
there are appropriate working groups for that already.

- There are definitely applications, devices and networks for which 
current solutions are not suitable. 60 byte payloads, real problems with 
TCP over wireless and mobile networks and very limited bandwidth over 
multiple wireless hops in e.g. a LoWPAN are very real problems. The 
goal of 6lowapp should be to provide an application protocol totally 
suitable to this domain - not just a band-aid.

What I would like to see is that the solution we aim at in 6lowapp is 
able to easily be proxied into protocols that dominate applications in 
energy, building automation and M2M. Today this is mainly HTTP, but we 
see some SIP and SNMP as well. For this reason the work item features 
include both features from HTTP (Req-Res, REST methods) as well as from 
e.g. SIP (eventing) and e.g. peer-to-peer which is key for OASIS and
building
automation in general. The support of URIs and content-types are common 
to all. 

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

Great - and any more feedback on improving the charter text would be 
welcome too!

Zach

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