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
>