Apple

Hello,

When a server is very close to the client (Example: rtt = 3ms // rttvar = 5ms), retransmits on SYN segments may happen at ~30ms * tcp_syn_backoff.

This proves to be quite low, and some firewalls might consider it a SYN flood attach and filter the flows.

<--- tcpdump output

13:27:41.836561 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1058421536 ecr 0,sackOK,eol], length 0

13:27:41.912030 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1058421611 ecr 0,sackOK,eol], length 0

13:27:41.943154 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1058421642 ecr 0,sackOK,eol], length 0

13:27:41.974354 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1058421673 ecr 0,sackOK,eol], length 0

13:27:42.005248 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1058421703 ecr 0,sackOK,eol], length 0

13:27:42.036006 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1058421733 ecr 0,sackOK,eol], length 0

13:27:42.098058 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1058421793 ecr 0,sackOK,eol], length 0

13:27:42.221808 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,sackOK,eol], length 0

13:27:42.464327 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,sackOK,eol], length 0

13:27:42.945660 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,sackOK,eol], length 0

13:27:43.907802 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,sackOK,eol], length 0

13:27:45.831197 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,sackOK,eol], length 0

13:27:47.753153 IP w.w.w..238.53595 > x.x.x.7.9999: Flags [S], seq 24164707, win 65535, options [mss 1460,sackOK,eol], length 0

As you can see the first retransmit is not exactly at 30ms, but a bit more (depending on when the tcp timers get adjusted). However, from the first retransmit onwards, the TCP_REXMTVAL(tp) is 31ms.

t_srtt and t_rttvar are inherited from the cloned route, while the t_rttmin is reset after the first SYN to 30ms (hard-coded).

~ consta$ route get x.x.x.7 route to: a.a.net destination: a.a.net gateway: w.w.w.1 interface: en5 flags: <UP,GATEWAY,HOST,DONE,WASCLONED,IFSCOPE,IFREF> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 3 5 0 1500 0

I could also find a FreeBSD patch for the same issue committed in 2012:

http://svnweb.freebsd.org/base/head/sys/netinet/tcp_timer.c?r1=242260&r2=242259&pathrev=242260

=== cut here ===
When retransmitting SYN in TCPS_SYN_SENT state use TCPTV_RTOBASE,
the default retransmit timeout, as base to calculate the backoff
time until next try instead of the TCP_REXMTVAL() macro which only
works correctly when we already have measured an actual RTT+RTTVAR.

Before it would cause the first retransmit at RTOBASE, the next
four at the same time (!) about 200ms later, and then another one
again RTOBASE later.
=== and here ===

Although I don't think this is breaking any RFCs since the RTT was previously measured for the same destination and stored in the routing table entry, I do think that the FreeBSD way of resetting the retransmit timer based in TCPTV_RTOBASE for SYN segments is probably better than reusing the TCP_REXMTVAL macro.

Any opinions?

//Sorin