Subject: [6lowapp] hardware trends, new vs. existing protocols [Re: [6lowpan] 4861 usage in LLNs]

From: Kris Pister <[email-masked]>
Date: Mon, 09 Nov 2009 18:53:20 -0800

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Nov 2009 03:57:58 +0100

Hi Kris:

Nothing says that DHCP cannot be used in that world, for what DHCP is
for. 
The question is whether we can use DHCP as ND. 
My short answer is no, these are 2 different models, like a push and a
pull.
I agree with Jonathan that there are good reasons why the flows in
6LoWPAN ND look so much like DHCP.
Where I disagree is pushing the analogy as far as getting confused
between the 2.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kris Pister
>Sent: mardi 10 novembre 2009 03:53
>To: Jonathan Hui
>Cc: Carsten Bormann; 6lowpan; [email-masked]
>Subject: [6lowpan] hardware trends, new vs. existing protocols [Re:
4861 usage in LLNs]
>_______________________________________________
>6lowpan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 10 Nov 2009 12:46:39 +0900

> possible'), rather than inventing something new.

I'm a big fan of not reinventing the wheel.
When what we need is a cup, however, we should not try to use wheels.
I have lots of experience with misappropriating protocols

Gruesse, Carsten

---

From: "Stuber, Michael" <[email-masked]>
Date: Mon, 9 Nov 2009 19:56:49 -0800

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-masked] [mailto:[email-masked]] On
Behalf Of Kris Pister
Sent: Monday, November 09, 2009 6:53 PM
To: Jonathan Hui
Cc: Carsten Bormann; 6lowpan; [email-masked]
Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861
usage in LLNs]

ksjp

---

From: "Stuber, Michael" <[email-masked]>
Date: Mon, 9 Nov 2009 19:58:15 -0800

So Carsten, are you volunteering to guide us on the best way to
misappropriate the protocol?  
:)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carsten Bormann
Sent: Monday, November 09, 2009 7:47 PM
To: Kris Pister
Cc: 6lowpan; [email-masked]
Subject: Re: [6lowpan] hardware trends,new vs. existing protocols [Re:
4861 usage in LLNs]

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Nov 2009 05:21:09 +0100

Hi Michael;

To be very clear, I have nothing against using / optimizing DHCP in
LoWPAN. All the contrary.
A great item for rechartering I suspect. Just don't call it ND. 

Note that even if an address is obtained via DHCP, it has to be DADed
through ND. 
And if a backbone is used, the address has to be proxied. Etc...

IOW, DHCP is an alternate to SLAAC to get an address (and other stuff),
but the ND draft is still needed. 
DHCP does not remove the need for ND, never did still does not.

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stuber, Michael
>Sent: mardi 10 novembre 2009 04:57
>To: Kris Pister; Jonathan Hui
4861 usage in LLNs]
>Subject: [6lowpan] hardware trends, new vs. existing protocols [Re:
4861

---

From: "Stuber, Michael" <[email-masked]>
Date: Mon, 9 Nov 2009 20:40:35 -0800

I realize that I'm new here, and I may be asking questions that have
already been hashed to death, but I confess I don't feel think that DAD
is appropriate on 802.15.4 mesh networks, unless the scope is limited to
the immediate neighbors.  Imagine a PAN with hundreds of nodes trying to
form.  

I understand that this may run afoul of the v6 RFCs, but I believe the
idea with 6LowPAN was to have an adaption for 802.15.4 networks, and I
believe this would be a reasonable adaption.  I for one am willing to
give up mesh-wide DAD in this context.  

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Monday, November 09, 2009 8:21 PM
To: Stuber, Michael; Kris Pister; Jonathan Hui
Cc: Carsten Bormann; 6lowpan; [email-masked]
Subject: RE: [6lowpan] hardware trends,new vs. existing protocols [Re:
4861 usage in LLNs]

Hi Michael;

Pascal

4861 usage in LLNs]

4861

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Nov 2009 05:48:14 +0100

Hi Michael:

My take is that address ownership and uniqueness is a fundamental
assumption of the IPv6 architecture and it must be ensured.
The current ND does that at low cost. Basically similar to the cost of
DHCP, with similar flows.

Pascal

>From: Stuber, Michael [mailto:[email-masked]]
>Sent: mardi 10 novembre 2009 05:41
>To: Pascal Thubert (pthubert); Kris Pister; Jonathan Hui
4861 usage in LLNs]

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 9 Nov 2009 20:47:22 -0800

My read on 4861 and 6LowPAN-ND (and prior knowledge of DHCP) would indicate
that 6LowPAN-ND is still needed as Pascal points out.  Does everyone agree
with this? 

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stuber, Michael
Sent: Monday, November 09, 2009 8:41 PM
To: Pascal Thubert (pthubert); Kris Pister; Jonathan Hui
Cc: Carsten Bormann; 6lowpan; [email-masked]
Subject: Re: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861
usage in LLNs]

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Monday, November 09, 2009 8:21 PM
To: Stuber, Michael; Kris Pister; Jonathan Hui
Cc: Carsten Bormann; 6lowpan; [email-masked]
Subject: RE: [6lowpan] hardware trends,new vs. existing protocols [Re:
4861 usage in LLNs]

Hi Michael;

Pascal

4861 usage in LLNs]

4861

---

From: Kris Pister <[email-masked]>
Date: Mon, 09 Nov 2009 22:12:03 -0800

> 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

---

From: Shidan <[email-masked]>
Date: Tue, 10 Nov 2009 01:20:39 -0500

+100

On Tue, Nov 10, 2009 at 1:12 AM, Kris Pister <[email-masked]>wrote:

> 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.
>
> 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:
>
>> 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
>>
>> 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.
>> 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:
>>
>>
>>> 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,
>>>
>>>
>>
>>
>>
>>> 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
>>>
>>>
>>
>>
>>
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Nov 2009 09:14:26 +0100

Hi Kris:

I would adhere to your idea but not that it applies to 6LoWPAN ND.

We are not rewriting IP from scratch. We are not even reinventing ND. 

We are adding another mechanism to the NDP suite, which already counts a
number of them (3122, 4861, 4862...).

It is a surprise for nobody that we have more than one classical IGP or
MANET protocol. In fact, MANET is working on one reactive and one
proactive protocol. Why would there only be one ND flavor? Should that
be at all cost? Hopefully, ND is not so cast in stone that we can't
improve it for new purposes. That would be the real bad news.

This additional mechanism goes along the sense of history:

1) it is proactive. 
In general, global flooding and centralized registries are extremes and
apply to very different scales and goals. 
You'll find protocols that occupy different places on a scale between
with those 2 extremes, with different optimization goals.

2) it is compatible with the other mechanisms
You can run it together with 4861 on ethernet or together with 3122 on
FR/ATM. In a same way that you can do NS/NA and RS/RA on a same link. It
is just an additional mechanism that provides additional benefits but
not a replacement though there's intersection for DAD and for address
resolution between host and router. 

3) It provides new benefits
Specifically, it is a way to grant the right to use an address over a
link, this grant including the validation that the address is unique.
There's a WG (SAVI) at the IETF dealing with one of the limitations of
the reactive ND. 
They end up snooping ND flows to reconstruct what may be the owners of
IPv6 addresses; A proactive registration resolves this.

4) It is lightweight
The model for that new operation is that the node only needs connect to
its router(s). IOW the protocol addition operates with an implicit not
on link model. This yields a low footprint both on the node and in the
air. 

5) It scales
Using a backbone that interconnects the white boards, the new mechanism
enables a subnet to grow pretty large. The spec uses proxy (4861) ND
there but other mechanisms like TRILL could be put in place.

6) It DADs, it ROLLs, and it moves
The new registration messages are designed to be extendable to enable an
end-node to join a RPL network. DAD using a distributed registry enables
a solid Address Duplication avoidance without the hassle of multicast.
Transparent mobility within the subnet is ensured by the protocol
operation between the registries. The mechanism also detects duplicate
MACs, an 'attack' that might be uncommon today but might appear more and
more as forgery speads in this domain. The alternate on the table is not
to do DAD and call it compliant to 4861.

I see people raising larger-than-life red flags to preserve their
precious pre-standard implementation, inflating the effort to make it
look either huge, incompatible, or a dead end that will not benefit from
further work on ND. I think none of this is true. If we do our job well,
with the help and support from 6MAN, then we can make this mechanism a
lot more generic than meets the eyes, with application on all sorts of
network, and thus an integral piece of ND from then on.

It seems clear to me that the resolution for the 6LoWPAN ND problem
cannot come from 6LoWPAN alone. 

Most of the objections that we see can be alleviated if 6MAN:
* adheres to the new model and completes it into a generic support
* confirms whether DAD is still required these days or whether has
become an obsolete commodity that we can live without with no hassle

The other way around, if 6MAN thinks that we are really on a dead end,
it would save a lot of time and friendly fire to let us know ASAP.

Either way, I think that 6LoWPAN needs external help.

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kris Pister
>Sent: mardi 10 novembre 2009 07:12
>To: Stuber, Michael
>Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing
protocols [Re: 4861 usage in LLNs]
4861

---

From: "Stuber, Michael" <[email-masked]>
Date: Tue, 10 Nov 2009 02:23:11 -0800

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.

-----Original Message-----
Sent: Monday, November 09, 2009 10:12 PM

 > Abandoning the installed base just goes to reinforce the idea  > that
IP isn't an appropriate technology for things.

ksjp

> 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

> from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 
> 32bit processor, and they aren't made in cutting-edge processes yet
either.
> optimized set of *existing* protocols that serve our needs, that run 
> on the existing new low-cost hardware (not the old workhorses). Let's

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Nov 2009 08:34:08 -0500

From participation in other working groups, discussions about  
encoding, known as the famous binary vs. text discussion, have a long  
and unproductive history. If this is to be more than assertions and  
argument-by-authority, proponents of feature-restricted or special- 
purpose protocols have the burden of proof: They have to show, based  
on realistic assumptions and real-world measurements, that more  
general techniques don't work in an interesting set of cases. Just  
saying that you can construct a network where a meter wants to tell  
its life story every ten seconds to 1000 light bulbs equipped with 2- 
bit processors all on the same PAN isn't too helpful unless this is a  
realistic deployment scenario. (I'm not saying anybody has done this  
so far, but we've come close.) In particular, I'd like to see  
observation-based estimates of message and bit rates for likely  
deployment scenarios. Even a 20 kb/s network can shovel 160,000 bytes  
a minute - that's a lot of air time for meters to fill.

 From experience, binary and other special-purpose encodings often  
only save 20 or 50%, i.e., not enough to make a fundamental difference  
and the processing effort is also often exaggerated. This is  
particularly true once you add crypto to the mix, which tends to  
completely dominate simple processing like embedded web servers.

We are unlikely to get away with protocols that ignore security or  
rely on non-crypto mechanisms going forward, so focusing on whether it  
takes 1 or 10 bytes to turn on a lightbulb isn't likely going to help  
much if the signature takes 500 bytes.

I also agree with the deployed-base fallacy. In real life, much of  
that base is never upgraded - often because remote upgrades simply  
aren't supported. By the time you send a technician to the household  
to swap the EPROM, the hardware cost is in the noise compared to the  
cost of the truck roll.

In such cases, it's much better to run the old, insecure and  
inflexible protocol in parallel with the new version for more capable  
hardware.

Henning

On Nov 10, 2009, at 1:20 AM, Shidan wrote:

> +100
>
> On Tue, Nov 10, 2009 at 1:12 AM, Kris Pister  
> <[email-masked]> wrote:
> 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:
> for
> 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,  
> 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:
>
> 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

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 10 Nov 2009 12:22:58 -0500

Date: Mon, 09 Nov 2009 22:12:03 -0800
   From: Kris Pister <[email-masked]>

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

---

From: Kris Pister <[email-masked]>
Date: Tue, 10 Nov 2009 11:13:24 -0800

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

---

From: Shidan <[email-masked]>
Date: Tue, 10 Nov 2009 18:00:09 -0500

Specially with respect to energy management, I don't think anyone is
suggesting IP doesn't fit the bill today. Rather, to the contrary, many
including myself, find it less clear if it's really necessary to redefine
everything proposed to meet today's use cases. I'm not saying it's not, but
just that it needs more careful analysis.

What Kris is saying on the state of current technology and where it is
headed, unlike some of the opposing arguments I've witnessed in this group,
is very clear and understandable to me. I think what would alleviate
everyones concerns, are equally clear arguments based on numbers, facts and
use cases as to why we need an overhaul of everything.

---
Shidan Gouran

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 10 Nov 2009 14:58:54 -0800

Hi Kris,

Prior to all of the wireless work I have done in the past 10 years, I worked
at a specialty edge router company.  We worked in large data centers
migrating serial protocols (bisync, X.25, etc.) to IP.  This work did
actually require new IETF protocols and extensions (MPLS, reliable
multicast, etc).   

I think for 6LowPAN to proliferate, we need to partially do what you suggest
(limit where possible creating new protocols) but augment existing IETF
standards as well.  I really see the CoRE work aligning with that vision
since we are mapping it to a RESTfull HTTP deployment which has precedence
in current web services.  Having CoRE re-use existing transports and
security is critical

There was one thing missing from your note on new hardware:  cost.
Lowering the bar on cost with CoRE will allow the technology to be deployed
in places where new ARM processors with 192K flash/etc are too expensive.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Kris Pister
Sent: Tuesday, November 10, 2009 11:13 AM
To: Richard Kelsey
Cc: [email-masked]; [email-masked]
Subject: Re: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861
usage in LLNs]

Richard -

ksjp

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 10 Nov 2009 18:13:04 -0500

Date: Tue, 10 Nov 2009 11:13:24 -0800
   From: Kris Pister <[email-masked]>

   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.

Kris,

Their wonderfulness aside, those chips are not what the
6lowpan charter describes.  Yes, I agree that rechartering
for bigger platforms would make our job easier, and could
reduce the number of new protocols needed.  I am not arguing
for or against it, just asking you if you are proposing that
we amend the charter.  If not, then we should use the specs 
that it has.
                            -Richard Kelsey

---

From: Robert Cragie <[email-masked]>
Date: Wed, 11 Nov 2009 00:25:06 +0000

So it is again down to trying to find the intersection between 
well-established and well-known protocols which work in networks with 
limited resources whose nodes have limited resources. There is a chance 
that despite the extent of the IETF smorgasbord, existing protocols may 
need to be tweaked or updated to accommodate these requirements. 
However, this must be the underlying aim - not to reinvent, but to take 
verbatim where possible and adapt where necessary. Where there is a 
clear demand, solutions will appear based on existing protocols plus 
adaptations - for example, VoIP.

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

---

From: Vlad Trifa <[email-masked]>
Date: Wed, 11 Nov 2009 09:19:40 +0100

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:
> 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.
>
> 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.
>
> 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 -
>> which have 128kB and 192kB of flash and lots of RAM; like the  
>> 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:
>>>    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.
>>>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Nov 2009 17:47:10 +0900

[limiting reply set to 6lowapp trying to untangle this thread]

On Nov 11, 2009, at 17:19, Vlad Trifa wrote:

> bandwidth is a not-so-critical constraint

I don't think you can describe the difficulties of constrained nodes/ 
networks using a single metric.
Indeed, the peak bitrate of a wireless technology may not be so bad,  
but challenges remain that may make existing protocols hard to use.   
Or maybe they don't -- that's why we are not at all trying to funnel  
all communication from the constrained network through CoAP (or  
CoGIIs).  This *is* IP, after all.

Gruesse, Carsten

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Nov 2009 05:12:33 -0500

The charter is presumably a draft, not a consensus. The numbers in the  
charter seem to lack rigorous justification, so I'm not comfortable  
with them as they stand. So, yes, I'm suggesting to either drop the  
numbers or make them more useful. In addition, memory size arguments  
are not terribly helpful unless each proposal will have a canonical  
implementation in the I-D. At least from my experience, people are  
very bad at estimating implementation complexity, except that one's  
own proposal by definition has lower complexity than any competing  
proposals.

Henning

---

From: Zach Shelby <[email-masked]>
Date: Wed, 11 Nov 2009 21:26:54 +0900

(again off the 6lowpan list, thread re-named)

Hi from Hiroshima,

I totally agree with Don below. There is a clear need for what CoRE is  
aiming to achieve, which was confirmed here at the IETF as well. For  
those of you that can and want to use HTTP, then please go ahead and  
do that.  CoRE is just augmenting the REST model with a different  
realization.

We had a really successful BOF here at the IETF, with helpful input to  
update the charter and move forward. Please give us a chance here to  
report back to the mailing list, and let you know what the next steps  
are. Be sure we will take the feedback on the CoRE charter into  
account from the mailing list as well.

Thanks,
Zach

On Nov 11, 2009, at 7:58 , Don Sturek wrote:

> Behalf
> IP.  We
> eye
> has
>> that
>> this

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain  
legally privileged information. If you are not the intended recipient,  
please contact the sender and delete the e-mail from your system  
without producing, distributing or retaining copies thereof.

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 11 Nov 2009 07:24:15 -0500

From: Henning Schulzrinne <[email-masked]>
   Date: Wed, 11 Nov 2009 05:12:33 -0500

   The charter is presumably a draft, not a consensus.

Yes, for 6lowapp.  6lowpan has an agreed-on charter.
My remarks concerned 6lowpan, and I should have
taken 6lowapp off of the reply list.  Mea Culpa.

                           -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Nov 2009 10:33:42 +0100

I'd agree with Don:

Adaptation is a survival trait. The radio paradigm is new and
interesting enough for IPv6 to make a quantum leap.
IPv6 will survive and it will adapt. The current ND work at 6LoWPAN is
just that, a backward compatible adaptation extension.

I see two schools, that I'd compare with WIFI infrastructure mode, and
WIFI adhoc mode.

In infra mode, the AP emulates the ethernet (transit link) behavior. 
--------------
Pros:
* L3 and above works as is. This feature was probably the key to radio
adoption as a LAN alternative.

Cons:
* As an L2 solution, it is limited to a "link". You end up with the
traditional hassle of broadcast domain, size of neighbor cache, etc...
* And as it hides the topology to routing, it shows the whole network as
one hop away. You end up with the traditional hassle of mixing mesh
under and route over, like IP and ATM.
* ESS only applies to radio MACs that can be bridged onto ethernet. The
802.11 was designed for this. The 802.15.4 MAC was not.
* As a deployed and workable solution, infra mode is now an inhibitor to
progress on adhoc mode. Most users do not even know that the alternative
exists and what it is for.

In ad-hoc mode, nodes are free to peer with whichever other nodes they
care to
--------------
Cons:
* need adapt L3 for new link and metrics behaviors (instable,
statistical, lossy, flapping rapidly) that L3 only approached and failed
to handle properly in the past.

Pros:
* adhoc mode does not artificially limit the set of peers, so a better
end to end path might be found, in and out.
* it place L3 in charge end-to-end, for a better integration of the
radio network within the larger IP network.

My take is that though (obviously) we do not want a foo per radio MAC,
we need a radio abstraction that looks like a radio, not like an
ethernet. 
This work has already started with 802.21, the metrics draft at ROLL, L2
adaptation draft at mobopts, etc... 
ND at 6LoWPAN is contributing to that larger movement.
And that movement must succeed, considering that radio fringe networks
are key to connect a new order of magnitude devices onto the Internet.

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Don Sturek
>Sent: mardi 10 novembre 2009 23:59
>To: 'Kris Pister'; 'Richard Kelsey'
4861 usage in LLNs]
Behalf
>I think that today's things are being designed with wonderful chips
like
>They can run IP, they will run IP, and in many cases they do run IP.
We
that
this