TCP parameters and interpreting tcpdump output

[Dieter]

Dieter> > 000016 IP bsd.63743 > src.65001: . ack 52 win 65535
Dieter> > 000011 IP bsd.63743 > src.65001: . ack 53 win 112	<------ why does  
Dieter> > the window suddenly shrink?

Chuck> I'd guess because both sides have requested that the connection  
Chuck> close

That's probably the case.  It just looked odd for the window size
to suddenly shrink.

Dieter> > The ack time is normally 12 or 13 microseconds, which seems to be  
Dieter> > okay.
Dieter> > But 99.5 milliseconds is *way* too slow, data will be lost.
Dieter> >
Dieter> > Is TCP sitting around waiting for a second packet, so that
Dieter> > it can be "efficient" and ack two packets at once?

Chuck> Yup.  Coalescing data before sending it results in less overhead.

Dieter> > What can I do to fix this?  Is there a knob I can turn to say
Dieter> > "ack every packet", or "only wait xxx microseconds for a 2nd packet" ?

Chuck> You can turn on TCP_NODELAY via setsockopt() to disable the Nagle  
Chuck> algorithm.  There are probably sysctl's you can tweak, also...

Bill> sysctl -d net.inet.tcp.delayed_ack
Bill> net.inet.tcp.delayed_ack: Delay ACK to try and piggyback it onto a data packet
Bill> 
Bill> That sysctl will turn it off for all network connections on the system.  You
Bill> can also set it on a per-socket basis using setsockopt and the TCP_NODELAY
Bill> option.  Some google searches on TCP_NODELAY will provide interesting
Bill> technical details.

That fixed one source of evil latency.  Thanks!