TCP parameters and interpreting tcpdump output

[Chuck Swiger]

On Dec 6, 2006, at 6:46 AM, Dieter 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?

I'd guess because both sides have requested that the connection  
close...it's a bit hard to say because you're not including complete  
data over the life of a connection, or even the sequence numbers.

("tcpdump -nttt" or "tcpdump -ntttv" would be more informative.)

> 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?

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

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

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

-- 
-Chuck