Re: [6lowapp] Where does TCP not work

[Lars Eggert <[e-mail]>]

Hi,

On 2009-11-2, at 17:11, Kris Pister wrote:
> 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.

yes.

> 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.

All that certainly helps, but I haven't seen much discussion on  
whether we all agree that we're only going to target scenarios for  
6LOWAPP for which we can make the assumption that such techniques will  
be in use.

>  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?

It's really difficult to predict this in general. Basically, the more  
your link/path looks like a wire, the better TCP will do. That means  
you want a relatively stable RTT, relatively stable available capacity  
and not too much (<1%?) loss.

The PILC WG published a bunch of very relevant documents, for example,

Advice for Internet Subnetwork Designers
http://tools.ietf.org/html/rfc3819

End-to-end Performance Implications of Links with Errors
http://tools.ietf.org/html/rfc3155

Advice to link designers on link Automatic Repeat reQuest (ARQ)
http://tools.ietf.org/html/rfc3366

End-to-end Performance Implications of Slow Links
http://tools.ietf.org/html/rfc3150

> 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?

I'm not saying that it can't be done in some scenarios - far from it.  
But there clearly are many scenarios where TCP won't work well.

Lars