Re: [6lowapp] Where does TCP not work

["Pascal Thubert (pthubert)" <[e-mail]>]

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