Re: [6lowapp] Where does TCP not work

[Jonathan Hui <[e-mail]>]

On Nov 2, 2009, at 5:40 PM, Lars Eggert wrote:

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

There seems to be an implicit assumption that the target link  
technologies will be similar, if not identical, to those targeted by  
ROLL.  For those networks, Kris is right that providing >99.9% end-to- 
end success rates with <1% duty cycle for both hosts *and* routers is  
yesterday's problem.  But, yes, we need to be more explicit about what  
link technologies we are targeting.

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


... and to decide whether or not TCP will work, we need to flip this  
thread to a top-down approach and first agree on the application  
requirements/use cases.  I have no doubt we can get TCP to work on a  
mesh of low-power, lossy links.  But are TCP's services/constraints  
appropriate for the application?  I can think of a variety of LLN  
applications that work just fine with TCP and others that could stand  
to use something else to improve latency, message efficiency, non p2p  
flows, multihoming, mobility,  etc.

--
Jonathan Hui