Kernel bug handling TCP_RTO_MAX?

Kernel bug handling TCP_RTO_MAX?

[Andreani Stefano]

Problem: I need to change the max value of the TCP retransmission timeout. 

Background: According to Karn's exponential backoff algorithm, when the receiver doesn't acknowledge packets for a while, the sender should retransmit the latest not acknowledged packet several times increasing the delay (RTO) since this delay reaches the Max Retransmission Timeout Value. 

Testing environment: Red Hat Linux release 7.2 (Enigma), Kernel 2.4.7-10 on an i686, Kernel 2.4.7-10.

Test details: I supposed this timeout in Linux was TCP_RTO_MAX, so I changed in /include/net/tcp.h the following line:

#define TCP_RTO_MAX	((unsigned)(6*HZ)) //It was: ((unsigned)(120*HZ))

Then I recompiled the kernel, rebooted the machine and tested the solution. The result I obtained was the same I had before this modification. 

I'm confident there isn't an error in the testing procedure because I already tested with a Solaris server the same procedure (changing the tcp_rexmit_interval_max variable) and it works. I'm just trying to reproduce the modification of that parameter in Linux. 

Could it be a bug on the RTO calculation algorithm, or there is something I mistook?

This is the first time I get into the linux kernel, so please be patient!

Thanks,

Stefano.

-------------------------------
        Stefano Andreani
    Freelance ICT Consultant
      H3G IOT Team - Italy
      tel. +39 347 8215965
   stefano.andreani.ap@h3g.it

Re: Kernel bug handling TCP_RTO_MAX?

[David S. Miller]

   From: "Andreani Stefano" <stefano.andreani.ap@h3g.it>
   Date: Thu, 12 Dec 2002 20:15:42 +0100

   Problem: I need to change the max value of the TCP retransmission
   timeout.

Why?  There should be zero reason to change this value.

Re: Kernel bug handling TCP_RTO_MAX?

[Richard B. Johnson]

On Thu, 12 Dec 2002, Andreani Stefano wrote:

> Problem: I need to change the max value of the TCP retransmission timeout. 
> 
> Background: According to Karn's exponential backoff algorithm, when the
> receiver doesn't acknowledge packets for a while, the sender should
> retransmit the latest not acknowledged packet several times increasing
> the delay (RTO) since this delay reaches the Max Retransmission Timeout
> Value. 
> 
> Testing environment: Red Hat Linux release 7.2 (Enigma), Kernel 2.4.7-10
> on an i686, Kernel 2.4.7-10.
> 
> Test details: I supposed this timeout in Linux was TCP_RTO_MAX, so I
> changed in /include/net/tcp.h the following line:
> 
> #define TCP_RTO_MAX	((unsigned)(6*HZ)) //It was: ((unsigned)(120*HZ))
> 
> Then I recompiled the kernel, rebooted the machine and tested the solution.
> The result I obtained was the same I had before this modification. 
> 
> I'm confident there isn't an error in the testing procedure because I
> already tested with a Solaris server the same procedure (changing the
> tcp_rexmit_interval_max variable) and it works. I'm just trying to
> reproduce the modification of that parameter in Linux. 
> 
> Could it be a bug on the RTO calculation algorithm, or there is something
> I mistook?
> 
> This is the first time I get into the linux kernel, so please be patient!
> 
> Thanks,
> 
> Stefano.

No file like /include/net/tcp.h is used in the compilation of the kernel.
Perhaps you mean ../linux-VERS/include/net/tcp.h (make sure you are
not compiling against some user-space headers).

Also, please fix your mailer line-wrap. Unix/Linux machines put '\n'
on or before the 80th character.

Once you check this out, search through that file, looking for "RTO".
There are many things that affect the retransmit interval. FYI the
current algorithm is correct and the minimum time to retransmit must
not be changed if you put this on a "live" network. If you were to
do this, your Linux machine gets an unfair advantage on a congested
network. This may seem great at first, but eventually your machine
will actually need to receive some some data. By taking over the
wire, you will end up with a bunch of hosts that were backed off,
now trying to jam packets into your machine. The result will be
poor performance because many packets will have to be dumped on
the floor, requiring an eventual retransmit. 

Also, remember to install the new kernel before you re-boot. Some
persons forget that they actually have to install the kernel. They
compile it, smile when it completes, then reboot. 

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: Kernel bug handling TCP_RTO_MAX?

[Matti Aarnio]

On Thu, Dec 12, 2002 at 08:15:42PM +0100, Andreani Stefano wrote:
> Problem: I need to change the max value of the TCP retransmission timeout. 
...
> #define TCP_RTO_MAX	((unsigned)(6*HZ)) //It was: ((unsigned)(120*HZ))
> 
> Then I recompiled the kernel, rebooted the machine and tested the 
> solution. The result I obtained was the same I had before this 
> modification. 

  Oh, you want to cap the retransmit time to 6 seconds so that
  TCP works (at least somehow) in a terribly lossy network ?

  Having that _low_ value at it isn't advisable in the general
  internet, but these modern mobile networks with paketized data
  are pain with dramatically varying latencies.  TCP works
  badly in such environments.  X.25 works better - to a degree..


  Changeing the value, and doing "make clean; make bzImage"
  should give you a kernel with it in.


..
> Could it be a bug on the RTO calculation algorithm, or there is 
> something I mistook?

  Possibly omitting "make clean" -- short-cutting it can be done
  by:  "rm net/ipv4/*.o"   I think..

> This is the first time I get into the linux kernel, so please be 
> patient!
> 
> Thanks,
> Stefano.
> -------------------------------
>         Stefano Andreani
>     Freelance ICT Consultant
>       H3G IOT Team - Italy
>       tel. +39 347 8215965
>    stefano.andreani.ap@h3g.it

/Matti Aarnio