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

[Kris Pister <[e-mail]>]

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