Re: [6lowapp] Where does TCP not work

Richard Kelsey <richard.kelsey@ember.com> Tue, 03 November 2009 15:30 UTC

Return-Path: <richard.kelsey@ember.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 D31B73A67E4 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 07:30:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level:
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599]
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 EdMCqNKcnjgi for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 07:30:03 -0800 (PST)
Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D69FF3A67D9 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 07:30:02 -0800 (PST)
Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 10:31:41 -0500
Date: Tue, 03 Nov 2009 10:27:29 -0500
Message-Id: <87ocnj6332.fsf@kelsey-ws.hq.ember.com>
To: Kris Pister <pister@eecs.berkeley.edu>
In-reply-to: <4AF006B9.3050101@eecs.berkeley.edu> (message from Kris Pister on Tue, 03 Nov 2009 02:32:25 -0800)
From: Richard Kelsey <richard.kelsey@ember.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> <4AF006B9.3050101@eecs.berkeley.edu>
X-OriginalArrivalTime: 03 Nov 2009 15:31:41.0091 (UTC) FILETIME=[BDB44F30:01CA5C9A]
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 15:30:03 -0000

   Date: Tue, 03 Nov 2009 02:32:25 -0800
   From: Kris Pister <pister@eecs.berkeley.edu>

   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.

Kris,

I hope we don't end up reinventing anything.  If we get the
layering right we can add a new protocols as needed and
still have everyone agree that the result is IP.  In
particular if 6LoWPAN and ROLL get their parts right, then
TCP will work out to the nodes and will be used when it is
appropriate.

I think that this thread is somewhat missing the point.  The
question isn't just whether TCP will fail to get data
delivered in this or that situation, but also, in the larger
picture, whether using TCP out to the nodes is a
cost-effective way to get the job done.  If someone has 10k
water meters sending one short packet a day, they may not
want to invest in the infrastructure needed to keep 10k TCP
connections open.  At some point in the process their data
will be available via TCP, but that doesn't require an
end-to-end TCP connnection down to each meter.  The great
thing about IP is that you get enormous flexibility in how
to structure networks and applications.

We cannot create a whole new protocol stack with a gateway
to convert between IP and our new stack.  What we can do is
provide alternatives where appropriate and take advantage of
the layering to allow people to choose which protocols they
use and, most importantly, when and where they want to do
any conversions.
                                -Richard Kelsey