0

I'm just trying to understand how retransmission feature works in the case of TCP on my linux box, but on the internet you can find really different information most of which is outdated or wrong, so I decided to ask the question here.

When it comes to RTO, in the linux kernel (file include/net/tcp.h) you have two options:

#define TCP_RTO_MAX     ((unsigned)(120*HZ))
#define TCP_RTO_MIN     ((unsigned)(HZ/5))

So there's a possibility of setting minimum and maximum time for a packet to be retransmited. Both of the above parameters depend on HZ, which can be specify in the kernel source, or you can customize it via CONFIG_HZ, at least in the case of adm64:

$ egrep HZ /boot/config-4.1.0-2-amd64
...
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250

So the minimum RTO should be around 50ms (250/5). But when you check the following wireshark output, you can see something very different:

enter image description here

It's one second. Is there an option that can also influence the RTO time?

Mikhail Morfikov
  • 966
  • 1
  • 10
  • 12
  • 2
    You are doing the calculations incorrectly. If `HZ` is 250, then `TCP_RTO_MIN` will be 50 ticks, not 50 ms. With 250 ticks per second, each tick will be 4ms, so it comes out to be 200ms. And the result will actually be 200ms regardless of what the value of `HZ` is, which is the point of writing `(HZ/5)` in the first place. – kasperd Sep 11 '15 at 07:21
  • Thanks for the info! So `HZ` doesn't matter in this case, `TCP_RTO_MIN` is 200ms always, so why wireshark shows 1s instead of 200ms? – Mikhail Morfikov Sep 11 '15 at 10:42
  • I think I know why there's 1s -- because of the SYN packet. I'm not sure because I can't find any info on SYN's RTO, but I think that in the case of SYN packets, RTO always equals 1s for the first SYN packet, 2s for second one (retransmission), 4s for another, and so on. I've just figured it out from `ss -i` output, so I don't know for sure. – Mikhail Morfikov Sep 11 '15 at 11:46
  • I haven't been looking at the implementation details to see exactly how it decides the timeouts. After the initial handshake timeouts could be decided based on measured roundtrip times, that would make more sense than a configuration option. But for the timeout during handshake that's not possible because no roundtrip has completed yet, thus no measurement of the roundtrip time exists. – kasperd Sep 11 '15 at 22:12

0 Answers0