Re: [6lowapp] Where does TCP not work

[Lars Eggert <[e-mail]>]

Hi,

On 2009-11-2, at 18:24, Jonathan Hui wrote:
> On Nov 2, 2009, at 5:40 PM, Lars Eggert wrote:
> 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.

I also should have mentioned that packet reordering is an issue. TCP  
basically treats a reordered packet as a loss, so you want that ration  
to be at most in the same ballpark as your loss ratio.

>>> 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'm not sure this can work. Sure, we have a set of applications  
identified now that we can guesstimate the requirements of. But the  
thing with a network is that once you build it, new apps will come.  
But there certainly is no harm in thinking about currently identified  
apps.

>  I have no doubt we can get TCP to work on a
> mesh of low-power, lossy links.

I wouldn't agree in to this generic statement. But I do believe that  
if you make some strong assumptions on radio technologies, routing,  
etc. that it can be made to work *under those conditions*.

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

That's another question, yes. But I'd see building new transport layer  
functions for 6LOWAPPs as an activity that would need some very strong  
ties to the TSV area, if it wouldn't be hosted there in the first place.

Lars