When checking to see if a window update should be sent to the remote peer,

don't force a window update if the window would not actually grow due to
window scaling.  Specifically, if the window scaling factor is larger than
2 * MSS, then after the local reader has drained 2 * MSS bytes from the
socket, a window update can end up advertising the same window.  If this
happens, the supposed window update actually ends up being a duplicate ACK.
This can result in an excessive number of duplicate ACKs when using a
higher maximum socket buffer size.

Reviewed by:	bz
MFC after:	1 month
This commit is contained in:
John Baldwin 2011-04-18 17:43:16 +00:00
parent 5d253e418f
commit da84b2e6c5

View File

@ -564,11 +564,19 @@ after_sack_rexmit:
long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) -
(tp->rcv_adv - tp->rcv_nxt);
/*
* If the new window size ends up being the same as the old
* size when it is scaled, then don't force a window update.
*/
if ((tp->rcv_adv - tp->rcv_nxt) >> tp->rcv_scale ==
(adv + tp->rcv_adv - tp->rcv_nxt) >> tp->rcv_scale)
goto dontupdate;
if (adv >= (long) (2 * tp->t_maxseg))
goto send;
if (2 * adv >= (long) so->so_rcv.sb_hiwat)
goto send;
}
dontupdate:
/*
* Send if we owe the peer an ACK, RST, SYN, or urgent data. ACKNOW