Re: [6lowapp] Where does TCP not work

["Pascal Thubert (pthubert)" <[e-mail]>]

Hi Don:

Another aspect of this is that there little room in the LoWPAN for
queuing packets so congestion should be avoided proactively when
possible; one way of doing that is to model the sensor data the way
voice calls are in larger network and perform some call admission
control / reservation. 

This is fine for regular sensor output but falls short for file
transfers, unless the transport is able to control its output rate.
There has been interesting protocols that used a rate-based flow
control, for instance IBM's RTP (HPR). Rate-based outperforms
window-based when dealing with very large TTL / very large network
countenance, such as deep space... and sensor networks.

But like Cullen said, we might need a 6Lowtrans or something to work
that out :)

Pascal

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
Behalf Of Don Sturek
>Sent: mardi 3 novembre 2009 15:00
>To: 'Kris Pister'
>Cc: [e-mail]
>Subject: Re: [6lowapp] Where does TCP not work
>
>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
>>
>
>_______________________________________________
>6lowapp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/6lowapp