Re: [6lowapp] Where does TCP not work

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

Hi Kris:

The long and correct answer is in RFC 5681 section 3.2. 

The short and partial one is that packets arriving out of order cause
additional churn (acks). 3 duplicate acks (still waiting for a same
delayed segment) will trigger a fast retransmission of that delayed
segment and temporarily reduce the number of outstanding segments
(congestion window).

TCP can live with long latencies but what it will not like too much is
if we spread packets over paths of different latencies for the reasons
above. I'm not so anxious about the effect on the congestion window as I
am about the energy and bandwidth cost from the additional acks and
retries being generated for nothing.

At the core, the problem goes beyond this.

I think that our buffers cannot properly accommodate a window-based
mechanism. The large TAT that we experience in those networks only makes
things worse. All this calls for rate-based, something like a SARATOGA,
with a Committed Information Rate mechanism that would use IP ECN bit
the way FR uses FECNs and BECNs, and some reservation/CAC mechanism in
the radio fringe to proactively obtain the required resources.

Cheers,

Pascal

>-----Original Message-----
>From: Kris Pister [mailto:[e-mail]]
>Sent: mercredi 4 novembre 2009 07:17
>To: Pascal Thubert (pthubert)
>Cc: Lars Eggert; [e-mail]
>Subject: Re: [6lowapp] Where does TCP not work
>
>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
>>