Re: [6lowapp] Where does TCP not work

[Kris Pister <[e-mail]>]

Pascal - I assume that we would only have path diversity inside the 
WPAN, and that the purpose of diversity would be to reduce latency, 
rather than increase it (e.g. RoLL, siblings when parents are having 
problems, etc.).  If you can't get the packet through to your preferred 
parent in a timely way, you try someone else in the hopes that you can 
still hit your latency target.  Yes?

Anyway, the goal of my original question was to understand what kinds of 
latency distributions would work.  I agree that it is easy to find 
distributions that will bring TCP to it's knees.  I'm hopeful that we 
can find some ways to make our meshes TCP-friendly under those 
circumstances when it is advantageous.  Under other circumstances (e.g. 
the ISA100 use cases that you presented) it's neither necessary nor 
efficient.

ksjp

Pascal Thubert (pthubert) wrote:
> Hi Lars and Kris:
>
>   
>>> 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.
>
> And path diversity when applied to TCP flows can have very adverse
> effects, if the packets are actually balanced over paths of very
> different latencies. A packet that is not lost but delayed in an
> alternate path will trigger fast recovery and cause the congestion
> window to drop. 
>
> Add a very long TTL to the mixture and you get a recipe for a very low
> throughput with packet duplication.
>
> MPTCP might offer some benefits if the subflows were routed on a given
> path each, but that's not what we are doing here so I'm not too hopeful
> though I'd like to dig more.
>
>
> Pascal
>