TIME_WAIT Assassination in FreeBSD???

[Robert Watson]

On Sat, 3 Sep 2011, Jarrod Lee Petz wrote:

> 3. Does FreeBSD handle this situation? How? I can't seem to find much info 
> on TIME_WAIT assassination in FreeBSD is mentioned in RFC 6056

I'm not familiar with the RFC side here, but I can confirm that FreeBSD will 
recycle TIMEWAIT connections more quickly than specified when load is very 
high.  This is done on the basis of allocated space; the sysctl:

   net.inet.tcp.maxtcptw

Instructs the stack regarding how much state to retain -- this is implemented 
by adjusting the allocation limit on the tcptw zone.  On my system, it seems 
to auto-tune to about 5000 connections, a value derived from the global limit 
on the number of sockets on the box I'm looking at -- your mileage may vary.

The resource limit case can occur in tcp_twstart(), when uma_zalloc() returns 
NULL on failing to allocate new TIMEWAIT state for a connection.  At that 
point, it forces an early scan of TIMEWAIT connections (which normally happens 
on 2msl intervals) with a 'reuse' argument of 1, authorising premature reuse. 
Without too close an analysis, it appears on face value to implement LRU: we 
reuse storage held by the connection that has been in TIMEWAIT the longest.

Robert