[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <B35A6FDF-714A-4226-AFF4-D12ECCD4A152@comsys.rwth-aachen.de>
Date: Thu, 28 Apr 2011 08:11:15 +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
Am 27.04.2011 um 23:41 schrieb Yuchung Cheng:
> AFAIK, FACK is disabled throughout the life of the connection after
> sender detects reordering degree > 3.
Right.
>
> But Alex said the reordering has some bugs. I suspect these bugs may
> affect FACK/sack auto-tuning.
No. It affects reordering detection only.
> Maybe Alex could describe the reordering
> bugs?
>
Yes, I can. With DSACK, you have two cases. DSACK below and above SEG.ACK.
DSACK below SEG.ACK is the come case. However, Linux doesn't calculate a
reordering extent in this case. We will fix this. In the other case, DSACK
above SEG.ACK, Linux quantifies the reordering as the distance between the
received DSACK and snd_fack. However, this is only correct if the reordering
delay is greater the RTT. We will fix that too.
As a result, in the first case, we waste the opportunity to calculate an
extent (loosing performance). In the second case we overestimate the
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