I totally second you Robert!
I think indeed, we shouldn't try to accomodate everything from enocean
light switches to servers, but rather enabling interoperability
between a wide class of devices with similar (limited) resources,
basically the same class of devices where 6lowpan could be used, and
basta.
Indeed, our focus should be really making the web of things a reality,
and make it scale as well, rather than take into account too much
bandwidth constraints and have them as central "design problem to
solve", as the actual problem we're trying to solve is different, and
bandwidth is a not-so-critical constraint (if we need very high data
rate and quasi real time constraints, nobody prevents us by using
gateways to connect legacy networks with other pure CoRE ones), as
long as CoRE can "semantically" accommodate different QoS with high
data rates transmitted through protocols that we're designed for that
(http). If the proxying or device-level core-enablement is
transparent, then it doesn't matter because interactions will be
CoREful (I like that term :) anyway.
It's not because a protocol was not made for something that we
should't use it, especially if it works fine for the scenarios we
consider. What's really missing is a concrete evaluation of the
scalability of HTTP-based scenarios for devices to show that it works
(or doesn't). Unless we have that, I don't see why we start with the
assumption that http-based solutions would be inherently bad and won't
scale because of the verbosity, and we need to get a grasp of their
actual limitations in that area.
Vlad
On Nov 11, 2009, at 1:25 AM, Robert Cragie wrote:
Regarding resource: There will be classes of devices which currently
will not support IP packets as the resource constraints are too
high, e.g. self-powered switches where the power budget is so
constrained you can barely get a squeak out of them. Do we want to
accommodate these devices in CoRE etc.? Probably not, and so it
makes sense to develop the network which suits those devices and
proxy them on a gateway. On the other hand, I think we have
established that we don't want to persistently continue to develop a
plethora of coexisting but non-interoperating networks all connected
to the internet through a hodge-podge of application gateways for
the sake of it. This is the reality today and it could be argued
that this has stifled the development of the highly-connected
"Internet of Things" we have all been dreaming about; it is a
solution but a clumsy one and one which doesn't scale well.
Regarding bandwidth: I remember back in the early 90's being able to
look at basic websites over a V32.bis (14400 bps max.) modem; whilst
the experience could be frustratingly slow, it was usable. And that
was an online, interactive experience. So whilst we need to consider
the arguments about bandwidth, I think that realistic traffic
scenarios need to be carefully looked at before ruling some
solutions out. I am sure there is already a plethora of experience
from many of the contributors to this group who already work in this
area.
So we come down to the limited ROM/RAM devices which sit uneasily
between the clearly capable devices currently available and the very
constrained and highly specific devices for certain types of
network. Which way do we want to push them? On the basis that these
are the devices which will become obsolete first, I would push them
towards the constrained side and say they are all proxied. In which
case, CoRE/ROLL/6LoWPAN becomes becomes focused on the more clearly
capable devices and therefore, as said at the beginning of this e-
mail, based on protocols taken verbatim where possible and adapted
where necessary.
Robert
Kris Pister wrote:
Richard -
I think that today's things are being designed with wonderful chips
like your Ember EM351 and EM357
which have 128kB and 192kB of flash and lots of RAM; like the
Jennic JN5148, the Freescale MC13224, the Dust DN2510.
They can run IP, they will run IP, and in many cases they do run
IP. We all agree on that, and we're all excited about that. The
debate centers on how many new protocols we need to invent, vs. how
many we can adopt or adapt, with the existing hardware, and with an
eye toward where technology trends are taking us. My concern, like
yours, is over the rate of adoption. If the fastest path to broad
adoption is to create new protocols for routing, ND, transport, and
applications, then by all means let's do that. I'm concerned,
however, that this has not been a uniformly successful approach for
wireless sensor networks in the past. :)
Many of us believe that we will see the fastest adoption by
minimizing the number of new protocols. We might be wrong, and
that's the debate.
ksjp
Richard Kelsey wrote:
Date: Mon, 09 Nov 2009 22:12:03 -0800
From: Kris Pister <[email protected]>
> Abandoning the installed base just goes to reinforce the idea
> that IP isn't an appropriate technology for things.
Michael - I think that we have the same goal, but I disagree
with that statement. I think that re-writing every protocol
from discovery through transport to applications, from scratch,
is what reinforces the idea that IP isn't an appropriate
technology for things.
I realize that there are pressures from an installed base, but
at this point it's a tiny fraction of the overall potential.
If we let the 1% installed base dictate the path for the next
99%, we should do our best to ensure that it's the right path.
Taking these two paragraphs together, you seem to be saying
that IP is an appropriate technology for tomorrow's things,
but not necessarily for today's. While the hardware will
obviously improve over time, we still need to pick some
target platform. The current 6lowpan charter gives 32K of
flash as an example and mentions 802.15.4 repeatedly. Are
you suggesting that we recharter?
The increasing capabilities of the hardware does give us the
reassuring prospect that the longer we take the solve the
problems the easier it will be to so.
-Richard Kelsey
_______________________________________________
6lowapp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowapp
_______________________________________________
6lowapp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowapp
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
