Re: [6lowapp] Where does TCP not work

[Jonathan Hui <[e-mail]>]

On Nov 2, 2009, at 6:38 PM, Lars Eggert wrote:

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

Of course.  There are ways to manage reordering but, as you said,  
requires making certain assumptions.

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

In the general sense, I agree.  I was suggesting this as an approach  
to answering this thread's subject line.  Indeed, the question of  
"will TCP work?" is a harder question.

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

I agree with you from a strict layering perspective with minimal  
assumptions about the lower layers.  I guess I come from a world where  
many of the applicable links (802.15.4, PLC, etc.) are still being  
specified in IEEE (15.4e, 15.4g) and IETF (6lowpan).  Members of those  
groups want to minimize complexity in their respective layers, of  
course.  But some layer has to deal with some of the hard problems.   
If pushing them into the lower layers is the right long term solution,  
then I say we guide the current efforts that way.  But if we're going  
to deal with all the hard problems at higher layers, then there's  
little incentive to do so at the lower layers.

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

Agreed.  Though the line seems to be a bit blurred because some  
suggest building transport-like mechanisms in whatever "app-level"  
protocol we're working on.

--
Jonathan Hui