Message-ID: <BANLkTinsHuP3XSSghfpYET=os9VcJ3FRDA@mail.gmail.com>
Date:	Wed, 27 Apr 2011 21:56:52 +0200
From:	Dominik Kaspar <dokaspar.ietf@...il.com>
To:	Yuchung Cheng <ycheng@...gle.com>
Cc:	Carsten Wolff <carsten@...ffcarsten.de>,
	John Heffner <johnwheffner@...il.com>,
	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
	Zimmermann Alexander <zimmermann@...s.rwth-aachen.de>,
	Lennart Schulte <Lennart.Schulte@...sys.rwth-aachen.de>,
	Arnd Hannemann <arnd@...dnet.de>
Subject: Re: Linux TCP's Robustness to Multipath Packet Reordering

Hi Yuchung,

Yes, FACK was enabled (as it is by default), but as Alexander already
pointed out, it should be disabled automatically when TCP detects
reordering.

However, I am not so sure how well this automatic turning off FACK is
done by Linux... I see a tendency that in situations with persistent
packet reordering, TCP with FACK enabled gets a lower performance than
if FACK is disabled right from the beginning of a connection.

Greetings,
Dominik

On Wed, Apr 27, 2011 at 7:39 PM, Yuchung Cheng <ycheng@...gle.com> wrote:
> Hi Dominik,
>
> On Wed, Apr 27, 2011 at 9:22 AM, Dominik Kaspar <dokaspar.ietf@...il.com> wrote:
>>
>> Hi Carsten,
>>
>> Thanks for your feedback. I made some new tests with the same setup of
>> packet-based forwarding over two emulated paths (600 KB/s, 10 ms) +
>> (400 KB/s, 100 ms). In the first experiments, which showed a step-wise
>> adaptation to reordering, SACK, DSACK, and Timestamps were all
>> enabled. In the experiments, I individually disabled these three
>> mechanisms and saw the following:
>>
>> - Disabling timestamps causes TCP to never adjust to reordering at all.
>> - Disabling SACK allows TCP to adapt very rapidly ("perfect" aggregation!).
>
> Did you enable tcp_fack when sack is enabled? this may make a (big)
> difference. FACK assumes little network reordering and mark packet
> losses more aggressively.
>
>> - Disabling DSACK has no obvious impact (still a step-wise throughput).
>>
>> Is there an explanation for why turning off SACK can be beneficial in
>> the presence of packet reordering? That sounds pretty
>> counter-intuitive to me... I thought SACK=1 always performs better
>> than SACK=0. The results are also illustrated in the following plot.
>> For each setting, there are three runs, which all exhibit a similar
>> behavior:
>>
>> http://home.simula.no/~kaspar/static/mptcp-emu-wlan-hspa-02-sack.png
>>
>> Greetings,
>> Dominik
>>
>> On Wed, Apr 27, 2011 at 11:57 AM, Carsten Wolff <carsten@...ffcarsten.de> wrote:
>> > Hi all,
>> >
>> > On Tuesday 26 April 2011, John Heffner wrote:
>> >> First, TCP is definitely not designed to work under such conditions.
>> >> For example, assumptions behind RTO calculation and fast retransmit
>> >> heuristics are violated.  However, in this particular case my first
>> >> guess is that you are being limited by "cwnd moderation," which was
>> >> the topic of recent discussion here.  Under persistent reordering,
>> >> cwnd moderation can inhibit the ability of cwnd to grow.
>> >
>> > it's not just cwnd moderation (of which I'm still in favor, even though I lost
>> > the argument by inactivity ;-)).
>> >
>> > Anyway, there are a lot of things in reordering handling that can be improved.
>> > Our group (Alexander, Lennart, Arnd, myself and others) has worked on the
>> > problem for a long time now. This work resulted in an algorithm that is in
>> > large parts TCP-NCR (RFC4653), but also utilizes information gathered by
>> > reordering detection for determination of a good DupThresh, fixes a few
>> > problems in RFC4653 and improves on the reordering detection in Linux when the
>> > connection has no timestamps option. We implemented "pure" TCP-NCR and our own
>> > variant in Linux using a modular framework similar to the congestion control
>> > modules. A lot of measurements and evaluation have gone into the comparison of
>> > the three algorithms. We are now very close(TM) to a final patch, that is more
>> > suited for publication on this list and integrates our algorithm into tcp*.
>> > [hc] without introducing the overhead of that modular framework.
>> >
>> > Greetings,
>> > Carsten
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists