Re: [6lowapp] Where does TCP not work

[Kris Pister <[e-mail]>]

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
>