Re: [6lowapp] Where does TCP not work
Cullen Jennings <fluffy@cisco.com> Tue, 03 November 2009 06:06 UTC
Return-Path: <fluffy@cisco.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 E61AE3A697A for <6lowapp@core3.amsl.com>;
Mon, 2 Nov 2009 22:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 DnPHfOoXcwb4 for
<6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 22:06:33 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by
core3.amsl.com (Postfix) with ESMTP id C99BB3A67D2 for <6lowapp@ietf.org>;
Mon, 2 Nov 2009 22:06:33 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com;
dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAMpX70qrR7Ht/2dsb2JhbADFIJc7hD0E
X-IronPort-AV: E=Sophos;i="4.44,672,1249257600"; d="scan'208";a="220554835"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com
with ESMTP; 03 Nov 2009 06:06:54 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
[128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id
nA366sdG003042; Tue, 3 Nov 2009 06:06:54 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);
Mon, 2 Nov 2009 22:06:54 -0800
Received: from [192.168.4.177] ([10.99.9.18]) by xfe-sjc-211.amer.cisco.com
with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 22:06:52 -0800
From: Cullen Jennings <fluffy@cisco.com>
To: <d.sturek@att.net>
In-Reply-To: <005c01ca5a86$9a3f2ef0$cebd8cd0$@sturek@att.net>
Impp: xmpp:cullenfluffyjennings@jabber.org
References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com>
<005c01ca5a86$9a3f2ef0$cebd8cd0$@sturek@att.net>
Message-Id: <DEF214D0-1324-493C-B855-E0A2018658A7@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 2 Nov 2009 23:06:51 -0700
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 03 Nov 2009 06:06:53.0199 (UTC)
FILETIME=[D6F259F0:01CA5C4B]
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 06:06:35 -0000
Makes sense, but I suspect that solving this type of problem is a bit outside of something we would do in the Apps area - seems like a an issues where you would want the type of expertise of a a WG in the transport area. Would it make sense to say something like today we need to run over TCP (and/or UDP) and in the future needs to be able to run over new transport protocols? On Oct 31, 2009, at 6:02 PM, Don Sturek wrote: > Hi Cullen, > > Sorry, I meant to provide some references on this issue. Basically, > here is > the problem: > 1) TCP was written back in the day when Ethernet was the primary > transport. > One key assumption made in TCP was that packet timeout was related to > congestion. TCP reacts to packet timeouts by adjusting the transmit > timing > and using back off. > 2) Wireless networks (especially mesh topologies) experience packet > loss as > a result of failure of the RF link. Note that IEEE 802.11 does not > typically exhibit this type of loss. The reason is that for IEEE > 802.11 > (actually WiFi) the last hop wireless link from the AP can be > guaranteed via > MAC level acknowledges and retries. The trouble with mesh links is > that > link errors are not propagated and, even if they are, result in route > re-establishment which violates the TCP timeout on the far end and > starts > the "congestion management" procedure in TCP (which actually makes the > problem worse as some of the links below indicate). > > I am not saying categorically that TCP does not work for wireless > links. I > am saying that for many wireless links, TCP does not work well (and > in some > extreme cases, at all). Here are some examples from the IETF > archives and > other industry trials...... > > http://www.rfc-editor.org/rfc/rfc4653.txt > http://www.sics.se/~adam/ewsn2004.pdf > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=686057 > > I used to have a more exhaustive reference list but I think if you > do a > search you will see this is a long standing problem.... > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On > Behalf > Of Cullen Jennings > Sent: Saturday, October 31, 2009 10:33 AM > To: 6lowapp@ietf.org > Subject: [6lowapp] Where does TCP not work > > > Multiple people have told me that TCP won't work on some of the types > of networks we want to run on. Anyway I'd like to understand a bit > more on why this is. > > I could go dig a 9600 baud modem out of my closet, set the MTU at 100, > and emulate 10% packet loss on server side and go try some things. I'm > relatively confidently TCP, HTTP, pop, imap, SSH, and TLS will all > work just fine. > > So, what are the network conditions that we think are going to cause a > problem for TCP? and, what might one do to make something that worked > better than TCP in these cases. > > Thanks, Cullen > > _______________________________________________ > 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)