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

[JP Vasseur <[e-mail]>]

Begin forwarded message:

> From: JP Vasseur <[e-mail]>
> Date: November 10, 2009 1:25:52 PM CEST
> To: "Stuber, Michael" <[e-mail]>
> Cc: "Kris Pister" <[e-mail]>du>, 6lowpan <[e-mail] 
> >, [e-mail]
> Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing  
> protocols [Re:  4861 usage in LLNs]
>
>
> 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: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Kris Pister
>> Sent: Monday, November 09, 2009 10:12 PM
>> To: Stuber, Michael
>> Cc: 6lowpan; [e-mail]
>> 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: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of Kris Pister
>>> Sent: Monday, November 09, 2009 6:53 PM
>>> To: Jonathan Hui
>>> Cc: Carsten Bormann; 6lowpan; [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>
>> _______________________________________________
>> 6lowapp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lowapp
>> _______________________________________________
>> 6lowapp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lowapp
>