Re: [6lowapp] Where does TCP not work

Lars -
 What's the best way to judge if a protocol stack will support TCP? I 
assume that it's some combination of end-to-end reliability and latency, 
and the statistics that govern them.
In the early days of sensor networks it was not uncommon to see 
end-to-end best-effort loss rates of 10% or more.  I don't think that 
anyone tolerates that kind of performance anymore.  With link-layer ACKs 
and path diversity in the routing layer I think that 99.9% for 
best-effort is now table stakes.  Is that good enough for TCP?  If it's 
not, how many nines do I need?  What kind of constraints are there on 
the latency distribution?

Clearly Adam and his students have gotten TCP to work over multi-hop, 
deeply duty-cycled 15.4 radios.  I think that there are probably several 
others who have as well.  Any feedback from people who have tried and 
failed?

ksjp

Lars Eggert wrote:
> Hi,
>
> On 2009-10-31, at 10:33, Cullen Jennings wrote:
>> 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.
>
> if by "work" you mean, "complete in some finite time", then yes 
> mostly. (Mostly, because there are timeouts that may kick in when a 
> connection is stalled for too long.) But my guess is that performance 
> would be extremely horrible (as in orders of magnitude worse than with 
> more reasonable loss rates <1%.)
>
> Lars
> ------------------------------------------------------------------------
>
> _______________________________________________
> 6lowapp mailing list
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp
>   