Re: [6lowapp] Where does TCP not work

["Don Sturek" <[e-mail]>]

Hi Kris,

Yes, there is a fundamental reason WiFi works well with TCP and other
wireless links don't:   the architecture of WiFi has been to have an access
point with a set of single wireless hops where data link acknowledges and
retries are employed AND where these operations can occur, where needed,
within the congestion time window TCP uses.

Have a look at an old RFC called TCP-SAT for an example where that time
window is violated.

Also, I think many of the references Lars supplied are good as well.

As you can tell, I agree with Lars on this (having worked with TCP over many
data link medium dating from the 1980's to present):  If you run TCP over
small networks or in very short time windows where the wireless link
exhibits behavior consistent with TCPs operating assumptions, you won't see
any issues.  If you operate TCP over a wireless link where the timeout
windows in TCP are invoked, you will see a slow degradation of operation
over time to where TCP is nearly unusable (all due to assumptions in TCP
around retry, in general.....)

Don


-----Original Message-----
From: Kris Pister [mailto:[e-mail]] 
Sent: Tuesday, November 03, 2009 3:19 AM
To: [e-mail]
Cc: 'Cullen Jennings'; [e-mail]
Subject: Re: [6lowapp] Where does TCP not work

Don - I like the WiFi example.  Clearly it's possible to make TCP work 
over wireless links.
If there had been a separate industry consortium based on 802.11 pushing 
DumbFi, a standard that didn't use L2 ARQ, then there would have been a 
group in the IETF trying to figure out a new transport protocol to use 
for these lossy links.

Do you believe that there is a fundamental reason why WiFi can work and 
15.4 radios can't?  I don't see any evidence that this is true.  Some of 
the early protocols in sensor networks were not well thought out, and 
the result is that there's a perception that 15.4 can't be as reliable 
as WiFi.  The reality is that 15.4 can be quite a bit *more* reliable 
than WiFi.

 >> 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
This remains the case with naive routing protocols, but it is *not* a 
general truth about mesh links.

ksjp

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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Cullen Jennings
> Sent: Saturday, October 31, 2009 10:33 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp
>
> _______________________________________________
> 6lowapp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp
>