[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <32030A20-D4FE-4D44-9DBF-464E42F11B90@comsys.rwth-aachen.de>
Date: Wed, 27 Apr 2011 19:53:59 +0200
From: Alexander Zimmermann <alexander.zimmermann@...sys.rwth-aachen.de>
To: Yuchung Cheng <ycheng@...gle.com>
Cc: Dominik Kaspar <dokaspar.ietf@...il.com>,
Carsten Wolff <carsten@...ffcarsten.de>,
John Heffner <johnwheffner@...il.com>,
Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
Lennart Schulte <Lennart.Schulte@...sys.rwth-aachen.de>,
Arnd Hannemann <arnd@...dnet.de>
Subject: Re: Linux TCP's Robustness to Multipath Packet Reordering
Hi,
Am 27.04.2011 um 19:39 schrieb Yuchung Cheng:
> 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.
It's not necessary to do it manually. Linux will disable FACK as soon as it
will detected reordering
Alex
//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: zimmermann@...rwth-aachen.de
// web: http://www.umic-mesh.net
//
Download attachment "PGP.sig" of type "application/pgp-signature" (244 bytes)
Powered by blists - more mailing lists