Re: [6lowapp] HTTP and SIP

[Shidan <[e-mail]>]

And just to be specific, when I'm talking about ZigBee, I'm referring in
specific to their defined data models and representations, not the whole
application architecture.

On Sun, Oct 11, 2009 at 7:18 PM, Shidan <[e-mail]> wrote:

> Thanks for this detailed explanation Don and your figures with regards to
> XML is very sound here.
> However for the purposes of the project I'm involved with, we've looked at
> the other side of the meter and the sessions we are defining with SIP are
> C12.19 sessions and very simple SIP messaging. The great thing is we can
> meld the control of meters with advanced communications infrastructure and
> take "unified communications", the concept of device mobility, security and
> accountability to another level. One of our partner companies has written an
> informative whitepaper on this architecture and if we get their permission
> we will send a link to the list if you are interested.
>
> Now going back to the home, and this is just my personal opinion, I don't
> believe standards like ZigBee are the right choice because they do indeed
> lock one to a particular layer 2 technology. However, I think they've done
> some great work on the application side and the application objects,
> profiles and such they have defined would take care of the issue you had
> without having to necessarily modify SIP or HTTP.
>
> Again, I'm not saying that a need for a whole new application protocol is
> warranted or not warranted as a fact, I'm just saying this is not evident to
> me and isn't a trivial assumption or something that can be reasoned without
> empirical evidence and considering some clear use cases. Lets change/modify
> what really needs to be changed based on the empirical evidence.
>
> Also unrelated, In response to Zach's note, we will be more than happy to
> lend a hand in helping define a standard that can map cleanly to SIP which
> might be useful for interfacing with even other applications such as XMPP
> which some leading demand reponse companies like Enernoc are using on the
> industrial side already. I will be engaging people in our group early next
> week and I'm sure they will be interested in working on this as well.
>
>
> On Sun, Oct 11, 2009 at 6:18 PM, Don Sturek <[e-mail]> wrote:
>
>>  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
>>
>>
>>
>
>