We have a few dedicated server rented in a data center with debian 7, kernel 3.2.
We use one of those servers as a database server. The network between our application server and database server is not dedicated to us but is used by other customers of the data center.
From time to time we recognize TCP retransmissions on this line. We think it is due to congestion or ddos attacks. Our provider tries to prevent attacks but is not always successful immediately of course.
Anyway. Usually our application server gets results from the database within 20 milliseconds as the database servers are very fast and the round-trip-time (RTT) average is 0.3 ms (so under 1 ms).
When a TCP packet is lost on this line the retransmission time out (RTO) kicks in. It is calculated by the round-trip-time but is at least 200ms. So when one packet needs to be retransmitted we have 220 milliseconds before our application server gets its data just because of the RTO.
For me rto_min=200ms seems to be way to high for a link with rtt under 1ms.
It is possible to set the rto_min with ip like this:
ip route change default via 144.76.176.65 dev eth0 rto_min 5ms
RTO is still calculated but can get down to 5ms as our RTT is very small.
Should I consider this or are there other TCP pitfalls I will fall into setting the rto_min so small? What is a resonable value for rto_min or is it better not to touch it?
0 Answers