Hi,
We have discovered a serious implementation bug in BicTCP on the Linux
kernels. Note that because BicTCP is ON by default, this affects all
users of kernel versions 2.6.8 and above.
For further details please see:
http://www.hamilton.ie/net/bic-fix/Linux%20BicTCP.pdf
and the patch is:
Index: linux-2.6.10/include/net/tcp.h
===================================================================
--- linux-2.6.10.orig/include/net/tcp.h Fri Dec 24 21:34:00 2004
+++ linux-2.6.10/include/net/tcp.h Thu Feb 17 14:13:14 2005
@@ -1280,8 +1280,7 @@
if (sysctl_tcp_bic_fast_convergence &&
tp->snd_cwnd < tp->bictcp.last_max_cwnd)
tp->bictcp.last_max_cwnd
- = (tp->snd_cwnd *
(2*BICTCP_1_OVER_BETA-1))
- / (BICTCP_1_OVER_BETA/2);
+ = tp->snd_cwnd - ( tp->snd_cwnd /
(BICTCP_1_OVER_BETA*2) );
else
tp->bictcp.last_max_cwnd = tp->snd_cwnd;
Yes, this looks like a bug, let me verify it first.
Why did you sit on this so long and go to all the trouble of making a
paper out of it?
We just wanted to be sure of the implementation against the official
BicTCP versions and that it was a real bug.
We are particularly concerned that the deployment of these experimental
protocols (and they're not even RFCs) are too premature and that we
think that they should be switched OFF by default to prevent
undesirable consequences to network stability. One concern is that such
protocols will steal (sometimes a lot of) bandwidth from normal network
traffic.
We wrote the paper as we (amongst others) are in the process of
rigourously validating and testing these TCP proposals over a wide
range of network environments There are also numerous other proposals
around (HSTCP, ScalableTCP, HTCP, FAST etc) that we are also testing
and we would be more than happy to provide patches (excluding FAST) and
experimental results as they become available.
Yee.
On Feb 21, 2005, at 15:50, Stephen Hemminger wrote:
> Yes, this looks like a bug, let me verify it first.
> Why did you sit on this so long and go to all the trouble of making a
> paper out of it?
>
On Monday 21 February 2005 08:47, Yee-Ting Li wrote:
>Hi,
>
>We have discovered a serious implementation bug in BicTCP on the
> Linux kernels. Note that because BicTCP is ON by default, this
> affects all users of kernel versions 2.6.8 and above.
>
>For further details please see:
>http://www.hamilton.ie/net/bic-fix/Linux%20BicTCP.pdf
>
>and the patch is:
>
>Index: linux-2.6.10/include/net/tcp.h
>===================================================================
>--- linux-2.6.10.orig/include/net/tcp.h Fri Dec 24 21:34:00 2004
>+++ linux-2.6.10/include/net/tcp.h Thu Feb 17 14:13:14 2005
>@@ -1280,8 +1280,7 @@
> if (sysctl_tcp_bic_fast_convergence &&
> tp->snd_cwnd < tp->bictcp.last_max_cwnd)
> tp->bictcp.last_max_cwnd
>- = (tp->snd_cwnd *
>(2*BICTCP_1_OVER_BETA-1))
>- / (BICTCP_1_OVER_BETA/2);
>+ = tp->snd_cwnd - ( tp->snd_cwnd /
>(BICTCP_1_OVER_BETA*2) );
> else
> tp->bictcp.last_max_cwnd = tp->snd_cwnd;
Could this explain why there was a lot of complaining that tcp was
slower back about then? (2.6.6 release time)
I've built and rebooted to a kernel patched as above, and will report,
but on my home network, the closest it will come to being congested
would be during an rsync or amdump from a client run, so it is
possible I will see no 'get my attention' differences. Nothing else
can approach me any faster than a 10base-T circuit.
In case no one else mentions it Mr. Li, patches such as this need a
"signed off by $yourname" line for record keeping, this just started
a few months ago.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.