Subject: [6lowapp] Really we need for HTTP on smart devices?

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Fri, 30 Oct 2009 13:02:39 +0100

Hello,
there is a lot effort to push HTTP and REST interfaces on smart objects
assuming that smart devices (sensor/actuators/readers) should act as Web
providers. On the other side, 6lowpan and other wireless sensor networks
are made by resource-constrained embedded devices so HTTP looks like too
resource expensive.

We are seeing a lot of proxying and gatewaying solutions to bring HTTP
and REST on the 6lowpan devices. But working with gateways and proxies
are always struggling especially at application level. My question here
is why we need to bring HTTP on smart objects?

Smart objects interact with the Internet as they like (and can) as
humans do. Humans type on a computer keyboard or play in front of the
iPhone camera while Things send sensing data or get commands to act on
the real world. Humans do not have an embedded HTTP server even if the
results of their actions (i.e. typing on a keyboard and playing in front
of a camera) are available as Web resources. In the same way, Things do
not need for an embedded HTTP server. Things interact with the Internet
using a lightweight protocol while the results of their interaction are
available on the Web as resources. It is a sort of "information shadow"
data that Things have on the Web. This data will be collected in a
suitable manner for the resource-constrained embedded devices and make
available as Web resource with HTTP and REST interfaces.

What do you think about it?

Regards,
Adriano

---

From: Vlad Trifa <[email-masked]>
Date: Fri, 30 Oct 2009 13:35:27 +0100

Hello,

Adriano: the web of things is exactly going beyond the "web  
information shadow" as you put it. We've been putting data from  
devices on the web since a decade, so what? nothing new there, but if  
you can turn devices by design into actual web actors (just as any  
other Web server), it open doors and completely new design  
possibilities as opposed to just make their data available on the web  
- it's a completely different (or broader) way of viewing things.

Well, I think the "HTTP is too heavy" argument is certainly valid when  
you have very tight/specific requirements and need to maximize the  
throughput of your communication. Of course it is a verbose protocol,  
but you might gain a lot of using it directly on devices, especially  
in terms of application level interoperability, and even more  
important for plug & play integration with the Web and Web  
applications. Let's put it that way: how many people know/use the  
zillions application protocols/middlewares available (I don't want to  
mention any, because many are excellent for specific applications, but  
I don't believe much in the *perfect* middleware) hundreds? maybe  
thousands? Ok and now how may people use http/xml? I think you get my  
point here.

Indeed, what you lose in performance (and it's not as bad as one  
thinks) you gain in terms of integrability. When I think smart homes,  
I think many constructors need to agree on a protocol. But I also  
think few messages here and there to control lights/HVAC and read  
energy meters with sub-second delay requirements. I don't think,  
thousands of messages per second nor high-frequency distributed  
sampling. Eventually, we want to reuse infrastructure that's already  
there (web), so why not use and adapt http/xml directly for that  
matter, as we need to design an application protocol anyway?

Of course one can use gateways for doing this, but if you can have  
directly http on devices, then your gateway simply become routers  
across physical interfaces, and it's much faster because you don't  
need to open or understand packets passing through.

Then if you think lots of concurrent people reading all types of http  
sensors from all types and constructors, then you can simply pop in a  
squid or any web cache, and voila, massively scalable infrastructure  
to store data (we got 20 years of experience with the web and the  
associated techs, so why reinvent the wheel when it rolls where you  
want?).

I shall stop here, and please have a look at some of our work, I think  
we try to motivate and illustrate that exact point well there:

http://www.vs.inf.ethz.ch/publ/papers/guinardSensorMashups09.pdf
http://www.vs.inf.ethz.ch/publ/papers/dguinard_09_WOTMashups.pdf

However, sorry I don't get the "humans don't have a web server"  
argument, what is your point with that?

Vlad

On Oct 30, 2009, at 1:02 PM, Adriano Pezzuto (apezzuto) wrote:

> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 30 Oct 2009 06:13:58 -0700

Hi Adriano,

We spent some time looking at the options for message exchange in Smart
Energy V2.  We knew we would be using self describing data (XML most likely)
and looked at the technologies that would allow the best integration with
existing internet/web solutions (basically trying to avoid a proprietary
binary protocol if we could).

I agree full HTTP would be too heavy on a small device.  However, using a
minimal set of HTTP features and a REST data exchange paradigm seemed to be
the most elegant solution.  I don't expect each device to host a web server
but I would expect some devices to do so  It just seemed that if we could
align on a known, deployed standard, adapted for small devices, we would
gain a lot in adoption.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adriano Pezzuto (apezzuto)
Sent: Friday, October 30, 2009 5:03 AM
To: [email-masked]
Subject: [6lowapp] Really we need for HTTP on smart devices?

Hello,

Regards,
Adriano

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Fri, 30 Oct 2009 15:59:23 +0100

Vlad/Don,
thanks for your feedbacks. Nice to see starting a debate here.

Vlad,
I know your work at the Web of Things and it's fine.
On the other side, today we do not see many real 6lowpan devices able to support HTTP on TCP. SunSpot is fine but for 6lowpan we have 60-80 bytes of payload and 10kbps in application throughput to deal with.

It looks that HTTP on 6lowpan is a sort of "I wish but I cannot" and gatewaying/proxying is only a compromise not a solution. I'm try to find different points of view, so my initial question.

Please have a look to this interesting paper from Tim O'Reilly and John Battelle:

http://www.web2summit.com/web2009/public/schedule/detail/10194
"
Many who talk about "the Internet of Things" assume that what will get us there is the combination of ultra-cheap RFID and IP addresses for everyday objects. The assumption is that every object must have a unique identifier for the "Internet of Things" to work.

What the Web 2.0 sensibility tells us is that we'll get to the Internet of Things via a hodgepodge of sensor data contributing, bottom-up, to machine-learning applications that gradually make more and more sense of the data that is handed to them. A bottle of wine on your supermarket shelf (or any other object) needn't have an RFID tag to join the "Internet of Things," it simply needs you to take a picture of its label. Your mobile phone, image recognition, search, and the sentient web will do the rest. We don't have to wait until each item in the supermarket has a unique machine-readable ID. Instead, we can make do with bar codes, tags on photos, and other "hacks" that are simply ways of brute-forcing identity out of reality. "

Regards,
Adriano

-----Original Message-----
From: Vlad Trifa [mailto:[email-masked]] 
Sent: venerdì 30 ottobre 2009 13.35
To: Adriano Pezzuto (apezzuto)
Cc: [email-masked]
Subject: Re: [6lowapp] Really we need for HTTP on smart devices?

Hello,

Vlad

---

From: Adam Dunkels <[email-masked]>
Date: Fri, 30 Oct 2009 16:04:05 +0100

> It looks that HTTP on 6lowpan is a sort of "I wish but I cannot" and gatewaying/proxying is only a compromise not a solution. I'm try to find different points of view, so my initial question.

HTTP is quite lightweight and not a problem for constrained devices per 
se. See e.g. http://www.sics.se/~adam/yazar09efficient.pdf

That said, HTTP may not always be the perfect solution for everything, 
but it is definitely achievable.

/adam
-- 
Adam Dunkels <[email-masked]>, +46707731614
http://twitter.com/adunk | http://www.sics.se/~adam/

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Fri, 30 Oct 2009 16:57:37 +0100

Thanks Adam,
It's a very interested work. 

Regards,
Adriano

-----Original Message-----
From: Adam Dunkels [mailto:[email-masked]] 
Sent: venerdì 30 ottobre 2009 16.04
To: Adriano Pezzuto (apezzuto)
Cc: Vlad Trifa; [email-masked]; [email-masked]
Subject: Re: [6lowapp] Really we need for HTTP on smart devices?

/adam

---

From: Vlad Trifa <[email-masked]>
Date: Fri, 30 Oct 2009 17:01:35 +0100

I totally agree with you! I don't think I ever said that "everything  
in the world must be a web server". Of course I'm in favor of rfid and  
hacks and barcodes to get data about the real-world on the web and  
even better when it doesn't need a web server or not a machine.

What you say really feels like you're trying to convince me about  
something we both know and agree with (just like every one else here I  
guess), so I don't see the point of discussing that.

When it comes to electronic devices I think HTTP is sufficient for  
many applications (again not all, just many), but as Adam points it  
out, it's not perfect for everything. I simply disagree with your  
comment "SunSpot is fine but for 6lowpan we have 60-80 bytes of  
payload and 10kbps in application throughput to deal with.".

I'll also add another example: Smews is a web server able to do comet (http://en.wikipedia.org/wiki/Comet_%28programming%29 
) with 100's of simultaneous subscribers (devices push http  
notifications to the subscribers) with decent amount of time. Smews  
needs 8kb and has been running on a standard msp430-based sensor node.

It's certainly slower than custom solutions, but it's there and works,  
and if you want to collect a temperature reading every minute, that's  
more than enough.

On Oct 30, 2009, at 3:59 PM, Adriano Pezzuto (apezzuto) wrote:

> On the other side, today we do not see many real 6lowpan devices  
> able to support HTTP on TCP. SunSpot is fine but for 6lowpan we have  
> 60-80 bytes of payload and 10kbps in application throughput to deal  
> with.
>
> It looks that HTTP on 6lowpan is a sort of "I wish but I cannot" and  
> gatewaying/proxying is only a compromise not a solution. I'm try to  
> find different points of view, so my initial question.
>
> Many who talk about "the Internet of Things" assume that what will  
> get us there is the combination of ultra-cheap RFID and IP addresses  
> for everyday objects. The assumption is that every object must have  
> a unique identifier for the "Internet of Things" to work.
>
> What the Web 2.0 sensibility tells us is that we'll get to the  
> Internet of Things via a hodgepodge of sensor data contributing,  
> bottom-up, to machine-learning applications that gradually make more  
> and more sense of the data that is handed to them. A bottle of wine  
> on your supermarket shelf (or any other object) needn't have an RFID  
> tag to join the "Internet of Things," it simply needs you to take a  
> picture of its label. Your mobile phone, image recognition, search,  
> and the sentient web will do the rest. We don't have to wait until  
> each item in the supermarket has a unique machine-readable ID.  
> Instead, we can make do with bar codes, tags on photos, and other  
> "hacks" that are simply ways of brute-forcing identity out of  
> reality. "
>
> Regards,
> Adriano
>
>
>