Reputation:
We have an home-brewed XMPP server and I was asked what is our server's MSL (Maximum Segment Lifetime).
What does it mean and how can I obtain it? Is it something in the Linux /proc
TCP settings?
Upvotes: 15
Views: 21816
Reputation: 2454
This looks like it can answer your question:
https://web.archive.org/web/20091028081219/http://seer.support.veritas.com/docs/264886.htm
I suggest that you ask why someone asked you this and find out how that applies to XMPP.
TCP/IP Illustrated volume 1 is online and describes 2MSL in more detail: Here
MSL is also described in the TCP RFC 793 as mentioned in wikipedia
Upvotes: 1
Reputation: 15757
You can also see a countdown timer for sockets using -o in netstat or ss, which helps show concrete numbers about how long things will wait. For instance, TIME_WAIT does NOT use tcp_fin_timeout (it is based on TCP_TIMEWAIT_LEN which is usually hardcoded to 60s).
cat /proc/sys/net/ipv4/tcp_fin_timeout
3
# See countdown timer for all TIME_WAIT sockets in 192.168.0.0-255
ss --numeric -o state time-wait dst 192.168.0.0/24
NetidRecv-Q Send-Q Local Address:Port Peer Address:Port
tcp 0 0 192.168.100.1:57516 192.168.0.10:80 timer:(timewait,55sec,0)
tcp 0 0 192.168.100.1:57356 192.168.0.10:80 timer:(timewait,25sec,0)
tcp 0 0 192.168.100.1:57334 192.168.0.10:80 timer:(timewait,22sec,0)
tcp 0 0 192.168.100.1:57282 192.168.0.10:80 timer:(timewait,12sec,0)
tcp 0 0 192.168.100.1:57418 192.168.0.10:80 timer:(timewait,38sec,0)
tcp 0 0 192.168.100.1:57458 192.168.0.10:80 timer:(timewait,46sec,0)
tcp 0 0 192.168.100.1:57252 192.168.0.10:80 timer:(timewait,7.436ms,0)
tcp 0 0 192.168.100.1:57244 192.168.0.10:80 timer:(timewait,6.536ms,0)
Upvotes: 12
Reputation: 9416
The MSL (Maximum Segment Lifetime) is the longest time (in seconds) that a TCP segment is expected to exist in the network. It most notably comes into play during the closing of a TCP connection -- between the CLOSE_WAIT and CLOSED state, the machine waits 2 MSL's (conceptually a round trip to the end of the internet and back) for any late packets. During this time, the machine is holding resources for the mostly-closed connection. If a server is busy, then the resources held this way can become an issue. One "fix" is to lower the MSL so that they are released sooner. Generally this works OK, but occasionally it can cause confusing failure scenarios.
On Linux (RHEL anyway, which is what I am familiar with), the "variable" /proc/sys/net/ipv4/tcp_fin_timeout
is the 2*MSL value. It is normally 60 (seconds).
To see it, do:
cat /proc/sys/net/ipv4/tcp_fin_timeout
To change it, do something like:
echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout
Here is a TCP STATE DIAGRAM. You can find the wait in question at the bottom.
Upvotes: 14