TCP: big bursts due to undos resulting from reordering

[Lennart Schulte <lennart.schulte@nets.rwth-aachen.de>]

Hi John, hi Ilpo,

at the moment I look on many TCP plots with reordering. When reordering
occurs there are some spurious retransmissions which are later undone by
e.g. DSACKs. This undo results in a very big burst of packets when
tp->reordering is high, since the function tcp_max_burst() returns
tp->reordering.

This behavior was introduced because of a bug when using SACK instead of
Reno. The thread concerning this fix can be found at [1].

Before the patch, which results from this thread, Linux has done a burst
of 3 packets and then slow started to the undone ssthresh value, which
is a much better way of handling an undo then it is after the patch.

Also I patched a kernel to use the old max_burst value of 3 again to see
if it has any effect. Then I set up some virtual nodes and emulated a
network with netem as it was done in the thread.
The settings are:
- RTT 40ms
- no congestion, application sending rate 20 Mbps
- forward path: reordering rate 20%, reordering delay 20ms
- timestamps on

Until now I have not found any evidence that the problem occurs (perhaps
because I don't get the settings right, since in the thread there is no
information concerning the settings for reordering and also the ones of
the sysctls).

My problem is to understand why the patch was necessary and under what
circumstances SACK has a lower throughput so that it may be possible for
me to find another way of fixing this without introducing and old bug.
Since I can't figure it out on my own I hope to get some insights this
way :)

Thanks,
Lennart Schulte

[1] http://marc.info/?t=120728958000004&r=2&w=2