Re: [6lowapp] Where does TCP not work

Hi Cullen,

This makes sense.

I think there is a Smart Grid bar BOF in Hiroshima.  This is probably in
response to the NIST Smart Grid roadmap and "Priority Action Plan" activity
(IETF is involved in priority action plan #1, IP for Smart Grid).  This
might be the place to suggest work on this topic in the Transport area.

Don

-----Original Message-----
From: Cullen Jennings [mailto:fluffy@cisco.com] 
Sent: Monday, November 02, 2009 10:07 PM
To: d.sturek@att.net
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Where does TCP not work

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
>