Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Self-made Lisp, in-memory database and hacking the Linux kernel: what's not to like about it ; )

I'm wondering: how does one decide to change the TCP_TIMEWAIT_LEN from 60 seconds to 20 seconds? 20 seems an arbitrary picked value: I understand that by doing so they can drastically cut down on the number of open connections after the last FIN is received, but why 20 instead of, say, 17 or, say, 9?



I think the value of 20 seconds is arbitrary, but there's a good reason why they don't lower it any further. With a protocol like TCP that guarantees reliable delivery, sometimes packets get resent to the server. If the server receives this resent packet after the connection has been closed and a new connection has been opened, it is possible that the server will accept this packet. As such, as part of closing a TCP connection, the connection sits in a TIME-WAIT state for 2*MSL seconds (MSL = maximum segment lifetime).

If you decrease the amount of time a connection sits in a TIME-WAIT state, you will increase the probability that a new connection could receive a packet from a previous connection. Given the latency of mobile networks, I would expect the probability of receiving a packet from a previous connection to be even higher.

If you're interested, the beginning of the following paper provides a great overview of the problem: http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/


On linux echo 20 > /proc/sys/net/ipv4/tcp_fin_timeout


The question was not "how do you do it once you decide" but "how do you decide on such an arbitrary replacement".

Also: "Do not be confused by the /proc/sys/net/ipv4/tcp_fin_timeout config item. The FIN TIMEOUT is not the same as the TIMEWAIT length." -- http://www.stolk.org/debian/timewait.html


The value was picked heuristically after measuring through Ganglia and a set of CLI tools the average TCP dialog duration between a set of mobile devices and our database and then performing a set of tests with varying TIMEWAIT lengths. The 20 second period is a sweet (and round :)) spot with < 0.01% of packets / day arriving after FIN. It's a good approach all in all, since our expected payload packet set is extremely small (just 1 on broadband connections with large MTUs).

- Panagiotis Papadomitsos, Head of Infrastructure @ BugSense


I was hoping it got chosen empirically. It's awesome that they were wise enough to not pick some theoretical best and calling it a day.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: