Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs]
Robert Cragie <robert.cragie@gridmerge.com> Wed, 11 November 2009 00:24 UTC
Return-Path: <robert.cragie@gridmerge.com>
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 596913A67B6; Tue, 10 Nov 2009 16:24:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.098
X-Spam-Level:
X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=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 73GWTNF3r+nU; Tue, 10 Nov 2009 16:24:47 -0800 (PST)
Received: from mail26.extendcp.co.uk (mail26.extendcp.co.uk [79.170.40.26]) by core3.amsl.com (Postfix) with ESMTP id 25FF328C25A; Tue, 10 Nov 2009 16:24:47 -0800 (PST)
Received: from client-82-3-89-126.manc.adsl.virginmedia.com ([82.3.89.126] helo=[192.168.1.66]) by mail26.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) id 1N811I-0003w4-2A; Wed, 11 Nov 2009 00:25:08 +0000
Message-ID: <4AFA0462.2090807@gridmerge.com>
Date: Wed, 11 Nov 2009 00:25:06 +0000
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Kris Pister <pister@eecs.berkeley.edu>
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>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------ms040802090508050607040607"
Cc: Michael.Stuber@itron.com, 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: robert.cragie@gridmerge.com
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: Wed, 11 Nov 2009 00:24:49 -0000
So it is again down to trying to find the intersection between well-established and well-known protocols which work in networks with limited resources whose nodes have limited resources. There is a chance that despite the extent of the IETF smorgasbord, existing protocols may need to be tweaked or updated to accommodate these requirements. However, this must be the underlying aim - not to reinvent, but to take verbatim where possible and adapt where necessary. Where there is a clear demand, solutions will appear based on existing protocols plus adaptations - for example, VoIP. Regarding resource: There will be classes of devices which currently will not support IP packets as the resource constraints are too high, e.g. self-powered switches where the power budget is so constrained you can barely get a squeak out of them. Do we want to accommodate these devices in CoRE etc.? Probably not, and so it makes sense to develop the network which suits those devices and proxy them on a gateway. On the other hand, I think we have established that we don't want to persistently continue to develop a plethora of coexisting but non-interoperating networks all connected to the internet through a hodge-podge of application gateways for the sake of it. This is the reality today and it could be argued that this has stifled the development of the highly-connected "Internet of Things" we have all been dreaming about; it is a solution but a clumsy one and one which doesn't scale well. Regarding bandwidth: I remember back in the early 90's being able to look at basic websites over a V32.bis (14400 bps max.) modem; whilst the experience could be frustratingly slow, it was usable. And that was an online, interactive experience. So whilst we need to consider the arguments about bandwidth, I think that realistic traffic scenarios need to be carefully looked at before ruling some solutions out. I am sure there is already a plethora of experience from many of the contributors to this group who already work in this area. So we come down to the limited ROM/RAM devices which sit uneasily between the clearly capable devices currently available and the very constrained and highly specific devices for certain types of network. Which way do we want to push them? On the basis that these are the devices which will become obsolete first, I would push them towards the constrained side and say they are all proxied. In which case, CoRE/ROLL/6LoWPAN becomes becomes focused on the more clearly capable devices and therefore, as said at the beginning of this e-mail, based on protocols taken verbatim where possible and adapted where necessary. Robert Kris Pister wrote: > 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 >> > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp >
- [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)