On Nov 10, 2009, at 11:23 AM, Stuber, Michael wrote:
To be clear, I am not arguing that we should re-write every protocol,
and certainly not from scratch. I think we need to be thoughtful
about
how we apply these technologies to the problem space. We need to be
efficient with all our resources. The chips may get more powerful,
but
the network (802.15.4) that we are targeting here will remain
constrained. No doubt there will come a day when different network
technologies are applied in this space, but at that point I don't
think
we're talking 6LoWPAN anymore.
I would word it a bit differently ... Yes we do need to be careful of
where we
apply technologies in light of specific constraints. But each time we
are tempted
to re-invent a protocol let's first try to demonstrate that we cannot
use an existing
protocol.
Note that we may at some point start using a more generic term than
6lowpans
and rather talk about LLNs (Low power and Lossy Networks) or any other
term:
they are many constrained networks using other low power technologies
than 15.4
JP.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Kris Pister
Sent: Monday, November 09, 2009 10:12 PM
To: Stuber, Michael
Cc: 6lowpan; [email protected]
Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing
protocols [Re: 4861 usage in LLNs]
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.
ksjp
Stuber, Michael wrote:
Life may be getting better, but that doesn't mean we have the wrong
target. Abandoning the installed base just goes to reinforce the
idea
that IP isn't an appropriate technology for things. Qualifications
for parts in appliances, meters, and cars may take much longer than
in
other consumer electronics. There are lots of products shipping
today
with
802.15.4 chips that do not match the (nicer) specs you outline below.
If we want to enable IP everywhere, we must acknowledge that small
footprint parts are an important part of "everywhere."
That said, I too am in favor of exploring optimized DHCP. It would
provide the flexibility of living in an edge router, or being
centralized. It is a well defined, characterized protocol.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Kris Pister
Sent: Monday, November 09, 2009 6:53 PM
To: Jonathan Hui
Cc: Carsten Bormann; 6lowpan; [email protected]
Subject: [6lowpan] hardware trends, new vs. existing protocols [Re:
4861 usage in LLNs]
+1 in favor of using optimized DHCP if possible (no opinion on 'if
possible'), rather than inventing something new.
As I've shared with several people in private emails recently, it's
pretty clear that lowpan nodes are going to get more capable moving
forward, not less. Why? Radios don't scale down in area when you
scale
CMOS processes. Today's 15.4 single-chip nodes are made in
technologies
that are several (maybe five?) generations behind the cutting edge.
This makes economic sense because the sales volumes don't support the
need for expensive mask sets yet.
When there's a volume application, and someone puts a 5mm2 radio into
modern CMOS, it just doesn't make sense to put 48kB of rom/flash and
10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and
many tens of kB of RAM, and the radio will still be by far the
biggest
thing on the chip.
Even the 48k/10k node from the (very nice) 6lowapp bof presentation
is
not up to commercial standards - it's a five year old, expensive,
academic platform - great for it's time, but old. Single-chip nodes
from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a
32bit processor, and they aren't made in cutting-edge processes yet
either.
Life is just going to get better. Let's try to find the smallest
optimized set of *existing* protocols that serve our needs, that run
on the existing new low-cost hardware (not the old workhorses). Let's
invent the absolute minimum of new "optimized" protocols, because
it's
not at all clear to me that we are optimizing the right things at
this
point. The less we invent, the broader the set of applications and
applications programmers we address.
ksjp
Jonathan Hui wrote:
On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote:
Again, entirely getting rid of a function is always the best
optimization.
Can we do that for DAD?
The *need* for DAD is the core question for me. As specified within
6lowpan-nd now, IPv6 addresses are maintained using a centralized
protocol. That protocol looks and smells like DHCP - there's
request/response, lease times, relays. The whiteboard may also
administratively assign addresses. So in the end, it's not clear to
me why we would need to *detect* duplicates when we essentially
*avoid* them from the beginning.
I've voiced my comment several times over the past 1+ years and
presented a draft that argues for the use of optimized DHCP in
Dublin,
so this is not new from my end. The fact that the current 6lowpan-
nd
document has evolved towards using DHCP-like mechanisms is not an
accident. But if what we do is DHCP-like, it would seem to make
sense
to utilize existing DHCP infrastructure rather than defining
something
new.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
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
