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

[Shidan <[e-mail]>]

+100

On Tue, Nov 10, 2009 at 1:12 AM, Kris Pister <[e-mail]>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 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
>