Thread (33 messages) 33 messages, 8 authors, 2011-06-21

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 detection
Which 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help