[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:20:04 PM CEST
> To: Kris Pister <[e-mail]>du>, Michael Stuber <[e-mail] 
> >
> Cc: 6lowpan <[e-mail]>rg>, [e-mail]
> Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing  
> protocols [Re:  4861 usage in LLNs]
>
>
> On Nov 10, 2009, at 7:12 AM, Kris Pister wrote:
>
>>
>> > 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 strongly second this statement. What worries me here is the  
> tendency to jump on new protocols without any evidence that existing  
> protocols can be used. Yes there are areas where we need new IP  
> protocols for constrained devices but there are also many more cases  
> where existing protocols could be re-used as such or with a small  
> adaptation.
>
>>
>> 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
>