Re: Linux TCP's Robustness to Multipath Packet Reordering
From: Carsten Wolff <hidden>
Date: 2011-06-21 11:40:27
Hi, On Tuesday 21 June 2011, Ilpo Järvinen wrote:
On Wed, 27 Apr 2011, Alexander Zimmermann wrote:quoted
Am 27.04.2011 um 18:22 schrieb Dominik Kaspar:quoted
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.Reordering detection with DSACK is broken in Linux. We will fix that in a couple of weeks...quoted
- Disabling SACK allows TCP to adapt very rapidly ("perfect" aggregation!).If you disable SACK, you will use the NewReno detectionWhich probably has some reordering over-estimate bugs on its own... (but I've forgotten details of my suspicion long time ago so please don't ask for the them).
the NewReno detection is clever, but there's no exact information it could utilize for a good metric, because it detects the event too late, when the information is already gone. In my experiments it always under-estimated the reordering extent, though. I also remmember thinking that the metric of the Eifel-detection has an off-by-one bug. Carsten