RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]]

[Stephen Hurd]

Harald Schmalzbauer wrote:
> Some experimental results:
> When rsyncing with windows, and FreeBSD is receiver, I see the same 
> ACK ever two segemnts, but speed is at 72MB/s.
> When FreeBSD is sender and Windows is receiver, it looks more I 
> expected. There are about 20 data segments before a ACK is returned. 
> And there are  TCP Window Update Segments, reflecting smaller receiver 
> buffers on the windows side. But this happens at a throughput of 
> 82MB/s!!! So the windows machine is behaving like I understand the TCP 
> flow control.
> Any explanation why the FreeBSD machine seems to ignore window size?

Yes, here we are in RFC1122:


      4.2.3.2 When to Send an ACK Segment

A host that is receiving a stream of TCP data segments can increase 
efficiency in both the Internet and the hosts by sending fewer than one 
ACK (acknowledgment) segment per data segment received; this is known as 
a "delayed ACK" [TCP:5].

A TCP SHOULD implement a delayed ACK, but an ACK should not be 
excessively delayed; in particular, the delay MUST be less than 0.5 
seconds, and in a stream of full-sized segments there SHOULD be an ACK 
for at least every second segment.


The idea of delayed ACKs is to allow an ACK to be sent with data if 
there will be data sent right away, not to combine ACKs... leaving out 
ACKs makes calculation of RTT problematical which causes performance 
problems all over the place... maybe the dearth of ACKs from the windows 
system is causing the problem?