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

["Pascal Thubert (pthubert)" <[e-mail]>]

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

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
Behalf Of Don Sturek
>Sent: mardi 10 novembre 2009 23:59
>To: 'Kris Pister'; 'Richard Kelsey'
>Cc: [e-mail]; [e-mail]
>Subject: Re: [6lowpan] hardware trends,new vs. existing protocols [Re:
4861 usage in LLNs]
>
>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: [e-mail] [mailto:[e-mail]] On
Behalf
>Of Kris Pister
>Sent: Tuesday, November 10, 2009 11:13 AM
>To: Richard Kelsey
>Cc: [e-mail]; [e-mail]
>Subject: Re: [6lowpan] hardware trends, new vs. existing protocols [Re:
4861
>usage in LLNs]
>
>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
>
>Richard Kelsey wrote:
>>    Date: Mon, 09 Nov 2009 22:12:03 -0800
>>    From: 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.
>>
>> 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
>>
>_______________________________________________
>6lowpan mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/6lowpan
>
>_______________________________________________
>6lowpan mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/6lowpan