Re: [6lowapp] Where does TCP not work

[Lars Eggert <[e-mail]>]

Hi,

one quick follow-up.

On 2009-11-2, at 19:15, Jonathan Hui wrote:
> On Nov 2, 2009, at 6:38 PM, Lars Eggert wrote:
>>> 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.

Of course. And currently, because there is more or less a single TCP  
standard for all deployment cases, a network needs to have certain  
properties in order for TCP to work well, so that the apps on top of  
it work well. This so far has meant that lower layers need to  
implement some functionality that results in a path that approximates  
the characteristics that TCP expects. (See the PILC documents.)

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


It's definitely debatable whether the approach that we've so far  
followed (making links and lower-layer network technologies implement  
stuff so that TCP/IP runs OK) is the One True Answer.

As we expand IP into environments that are very different from the  
"normal" Internet, it's not fully clear (to me at least) whether this  
approach will continue to be efficient. At the bar BOF in Stockholm, I  
made a strawman proposal that for 6LOWAPPs, we might instead start  
thinking about giving up on TCP and implementing a set of end-to-end  
transport functions that apps can pick & choose from, depending on  
their needs (reliability, uni/multicast, error protection, loss  
protection/FEC, flow control, etc.) Those functions may not need to be  
provided by a separate protocol with a header and a layer in the  
stack; we might make them available as a common library that apps link  
against, for example.

Lars