Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs]
"Don Sturek" <d.sturek@att.net> Tue, 10 November 2009 23:05 UTC
Return-Path: <d.sturek@att.net>
X-Original-To: 6lowapp@core3.amsl.com
Delivered-To: 6lowapp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21E928C1F9 for <6lowapp@core3.amsl.com>; Tue, 10 Nov 2009 15:05:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.287
X-Spam-Level:
X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEKP86V2fIS2 for <6lowapp@core3.amsl.com>; Tue, 10 Nov 2009 15:05:09 -0800 (PST)
Received: from smtp109.sbc.mail.gq1.yahoo.com (smtp109.sbc.mail.gq1.yahoo.com [67.195.14.39]) by core3.amsl.com (Postfix) with SMTP id 8E8DC28C0DD for <6lowapp@ietf.org>; Tue, 10 Nov 2009 15:05:09 -0800 (PST)
Received: (qmail 54426 invoked from network); 10 Nov 2009 22:58:57 -0000
Received: from host-160-85.meeting.ietf.org (d.sturek@133.93.160.85 with login) by smtp109.sbc.mail.gq1.yahoo.com with SMTP; 10 Nov 2009 14:58:57 -0800 PST
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: 1INt7CEVM1nDM.DbBcRvuNiWRB6nPLSmu69sk0ZZinc4ogtoQT1yDmoEMWZKN6eedpw4HR9upF_pbBH4WJBC2ucI5xiWsK2xGEvxnh_rcHRonFtNoEQCjFIgmrr0L23jZtb_OAmtBWanHjxFlwUK6eM6qCUVyxTJAbtRhFLIkecZQMVKBPf9PJ4CAK9Qtxyh5evAKmvA9_XpzBdSjqU8OUfkQ0RgFybOVDk5RmifGn369Ra_qIHihCbcHQKtW.j7oYOIvbV0JxTeKEheDepvC0aJFuDhsvhpAczGERaMbYbRKUpvwNWdSJjee9T27Q9N88eR5LTSNZpmU_U2dRHfDq0-
X-Yahoo-Newman-Property: ymail-3
From: Don Sturek <d.sturek@att.net>
To: 'Kris Pister' <pister@eecs.berkeley.edu>, 'Richard Kelsey' <richard.kelsey@ember.com>
References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <BCFFD6A3-8B4F-49CF-A657-DE34485134E1@tzi.org> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com> <4AF9BB54.7070006@eecs.berkeley.edu>
In-Reply-To: <4AF9BB54.7070006@eecs.berkeley.edu>
Date: Tue, 10 Nov 2009 14:58:54 -0800
Message-ID: <019f01ca6259$625528c0$26ff7a40$@sturek>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcpiOeUcq/TvAEg9RCGWZ32RY3XEYwAHlhSg
Content-Language: en-us
Cc: 6lowpan@ietf.org, 6lowapp@ietf.org
Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs]
X-BeenThere: 6lowapp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowapp>
List-Post: <mailto:6lowapp@ietf.org>
List-Help: <mailto:6lowapp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2009 23:05:09 -0000
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: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Kris Pister Sent: Tuesday, November 10, 2009 11:13 AM To: Richard Kelsey Cc: 6lowpan@ietf.org; 6lowapp@ietf.org 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 <pister@eecs.berkeley.edu> > > > 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 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan
- [6lowapp] hardware trends, new vs. existing proto… Kris Pister
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Pascal Thubert (pthubert)
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Carsten Bormann
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Stuber, Michael
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Stuber, Michael
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Pascal Thubert (pthubert)
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Stuber, Michael
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Pascal Thubert (pthubert)
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Don Sturek
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Kris Pister
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Shidan
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Pascal Thubert (pthubert)
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Stuber, Michael
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Henning Schulzrinne
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Richard Kelsey
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Kris Pister
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Shidan
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Don Sturek
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Richard Kelsey
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Robert Cragie
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Vlad Trifa
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Carsten Bormann
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Henning Schulzrinne
- Re: [6lowapp] Next steps Zach Shelby
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Richard Kelsey
- Re: [6lowapp] [6lowpan] hardware trends, new vs. … Pascal Thubert (pthubert)