TCP parameters and interpreting tcpdump output

[Bill Moran]

Dieter <freebsd at sopwith.solgatos.com> wrote:
>
> I found a couple more things that don't look right.
> 
> 000017 IP bsd.63743 > src.65001: . ack 52 win 65535
> 000107 IP bsd.63743 > src.65001: . ack 52 win 65535
> 000012 IP bsd.63743 > src.65001: F 52:52(0) ack 52 win 65535
> 000005 IP bsd.63743 > src.65001: F 52:52(0) ack 52 win 65535
> 000172 IP src.65001 > bsd.63743: . ack 53 win 4096
> 000004 IP src.65001 > bsd.63743: F 52:52(0) ack 53 win 4096
> 000003 IP src.65001 > bsd.63743: . ack 53 win 4096
> 000016 IP bsd.63743 > src.65001: . ack 52 win 65535
> 000011 IP bsd.63743 > src.65001: . ack 53 win 112	<------ why does the window suddenly shrink?
> 002366 IP src.rfe > bsd.12340: P 1:1317(1316) ack 1 win 4096
> 099554 IP bsd.12340 > src.rfe: . ack 1317 win 65535     <------ why does it take 99.5 millisec to ack?
> 
> The ack time is normally 12 or 13 microseconds, which seems to be okay.
> But 99.5 milliseconds is *way* too slow, data will be lost.
> 
> Is TCP sitting around waiting for a second packet, so that
> it can be "efficient" and ack two packets at once?

sysctl -d net.inet.tcp.delayed_ack
net.inet.tcp.delayed_ack: Delay ACK to try and piggyback it onto a data packet

That sysctl will turn it off for all network connections on the system.  You
can also set it on a per-socket basis using setsockopt and the TCP_NODELAY
option.  Some google searches on TCP_NODELAY will provide interesting
technical details.

-Bill