Re: [6lowapp] Where does TCP not work
Kris Pister <pister@eecs.berkeley.edu> Tue, 03 November 2009 10:32 UTC
Return-Path: <pister@eecs.berkeley.edu>
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 15AB93A69B8 for <6lowapp@core3.amsl.com>;
Tue, 3 Nov 2009 02:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 GDTIHytOWHjS for
<6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 02:32:20 -0800 (PST)
Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU
[169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 194693A6966 for
<6lowapp@ietf.org>; Tue, 3 Nov 2009 02:32:20 -0800 (PST)
Received: from [192.168.1.100] (c-24-4-148-227.hsd1.ca.comcast.net
[24.4.148.227]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU
(8.14.3/8.13.5) with ESMTP id nA3AWUvq009506 (version=TLSv1/SSLv3
cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Tue, 3 Nov 2009 02:32:31 -0800 (PST)
Message-ID: <4AF006B9.3050101@eecs.berkeley.edu>
Date: Tue, 03 Nov 2009 02:32:25 -0800
From: Kris Pister <pister@eecs.berkeley.edu>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com>
<5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com>
<4AEF832C.9050603@eecs.berkeley.edu>
<3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com>
<66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com>
<72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com>
<EB72DA52-70E1-404B-A507-4871720A1FA8@archrock.com>
<FD5C3C18-B400-4629-9BF8-E042FEF0919E@nokia.com>
<50D02497-17A6-4EF2-AC6E-FE783E48E071@archrock.com>
<6A2A459175DABE4BB11DE2026AA50A5D8DFDD6@XMB-AMS-107.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D8DFDD6@XMB-AMS-107.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Where does TCP not work
X-BeenThere: 6lowapp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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, 03 Nov 2009 10:32:21 -0000
Pascal - I think that these choices in isa100 were good ones, for the reasons that you listed. I'd summarize as "the legacy protocols in industrial automation aren't built around TCP". Do you believe that this will be true in 6lowapp? My opinion is that almost by definition (the "6" in the name), that TCP will be an important part of that future. I'm 100% sure that we'll find other ways of doing things as well, but it makes me nervous when it looks like we're trying to reinvent every protocol from bottom to top, and still call it IP. ksjp Pascal Thubert (pthubert) wrote: > Hi Jonathan: > > We went around that same question of transport at ISA100.11a. > > We ended up using a form of DTLS (over UDP) that 6LoWPAN actually > compresses efficiently. > > Why did we end up with this? > > - every app seemed to have very different requirement on transport. The > common ground was reduced to a secured datagram service. > > - we resolved to use the CCM provided by the chipset crypto engines > (same as used at L2) to save power. > > - ISA100 (client-server) apps that need ack usually have app layer ack > that carries some data back. Transport layer ack is there a costly and > unwanted operation. > > - Most of the data (buffered, eg readings repeated over and over) do not > require retries anyway > > - packet loss during TCP start can delay the connection for too long > (that's what started reliable UDP to pass dial numbers that later became > SCTP) > > - we considered other transports like DCCP but for a number of reasons > that include those middle boxes that know only TCP and UDP, we resolved > to stay with UDP with ECN passed up to the app layer. > > Cheers, > > Pascal > > >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >> > Behalf Of Jonathan Hui > >> Sent: mardi 3 novembre 2009 05:22 >> To: Lars Eggert >> Cc: 6lowapp@ietf.org >> Subject: Re: [6lowapp] Where does TCP not work >> >> >> On Nov 2, 2009, at 7:46 PM, Lars Eggert wrote: >> >> >>> It's definitely debatable whether the approach that we've so far >>> followed (making links and lower-layer network technologies >>> implement stuff so that TCP/IP runs OK) is the One True Answer. >>> >> Yes. >> >> >>> As we expand IP into environments that are very different from the >>> "normal" Internet, it's not fully clear (to me at least) whether >>> this approach will continue to be efficient. At the bar BOF in >>> Stockholm, I made a strawman proposal that for 6LOWAPPs, we might >>> instead start thinking about giving up on TCP and implementing a set >>> of end-to-end transport functions that apps can pick & choose from, >>> depending on their needs (reliability, uni/multicast, error >>> protection, loss protection/FEC, flow control, etc.) Those functions >>> may not need to be provided by a separate protocol with a header and >>> a layer in the stack; we might make them available as a common >>> library that apps link against, for example. >>> >> Certainly sounds like an interesting idea and it would be a breath of >> fresh air not to be encumbered by TCP. So can we afford to sacrifice >> interoperability with TCP-based tools/infrastructure? There are >> clearly people on both sides and it's not clear to me how to come to >> closure except to recognize both sides for the time being. >> >> -- >> Jonathan Hui >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp >
- [6lowapp] Where does TCP not work Cullen Jennings
- Re: [6lowapp] Where does TCP not work Don Sturek
- Re: [6lowapp] Where does TCP not work Lars Eggert
- Re: [6lowapp] Where does TCP not work Kris Pister
- Re: [6lowapp] Where does TCP not work Lars Eggert
- Re: [6lowapp] Where does TCP not work Jonathan Hui
- Re: [6lowapp] Where does TCP not work Lars Eggert
- Re: [6lowapp] Where does TCP not work Jonathan Hui
- Re: [6lowapp] Where does TCP not work Lars Eggert
- Re: [6lowapp] Where does TCP not work Jonathan Hui
- Re: [6lowapp] Where does TCP not work Cullen Jennings
- Re: [6lowapp] Charter and transports Zach Shelby
- Re: [6lowapp] Where does TCP not work Pascal Thubert (pthubert)
- Re: [6lowapp] Where does TCP not work Kris Pister
- Re: [6lowapp] Where does TCP not work Kris Pister
- Re: [6lowapp] Where does TCP not work Don Sturek
- Re: [6lowapp] Charter and transports Don Sturek
- Re: [6lowapp] Where does TCP not work Don Sturek
- Re: [6lowapp] Where does TCP not work Richard Kelsey
- Re: [6lowapp] Where does TCP not work Pascal Thubert (pthubert)
- Re: [6lowapp] Charter and transports Lisa Dusseault
- Re: [6lowapp] Charter and transports Don Sturek
- Re: [6lowapp] Charter and transports Lloyd Wood
- Re: [6lowapp] Where does TCP not work Pascal Thubert (pthubert)
- Re: [6lowapp] Charter and transports Pascal Thubert (pthubert)
- Re: [6lowapp] Charter and transports Lloyd Wood
- Re: [6lowapp] Charter and transports Zach Shelby
- Re: [6lowapp] Charter and transports Don Sturek
- Re: [6lowapp] Where does TCP not work Lars Eggert
- Re: [6lowapp] Where does TCP not work Don Sturek
- Re: [6lowapp] Where does TCP not work Kris Pister
- Re: [6lowapp] Where does TCP not work Kris Pister
- Re: [6lowapp] Where does TCP not work Pascal Thubert (pthubert)
- Re: [6lowapp] Where does TCP not work Pascal Thubert (pthubert)