Looking at some very old versions (4.3 BSD Reno for instance), the regular acks used to be sent only through these window updates. i.e. acks were sent only when the apps read the data. Acks are piggybacked with window updates. Or, delayed till the delayed ack timer expires if the apps is not reading. This would have had other issues with congestion control due to generating too few acks. When this was changed to send acks independent of apps reading the data, we now have lot more acks due to these window updates in addition to the regular acks.
Venkat ________________________________ From: David Malone <[EMAIL PROTECTED]> To: Rui Paulo <[EMAIL PROTECTED]> Cc: freebsd-net@freebsd.org; Kevin Oberman <[EMAIL PROTECTED]> Sent: Friday, November 28, 2008 1:36:04 PM Subject: Re: FreeBSD Window updates > Yes, this makes sense. Probably this is a bug since 4.4BSD-Lite. I had a look to see what Linux does - it only generates pure window updates in the case that the advertised window would change by a factor of two. I guess this practically eliminates these updates. I would guess that changing the code to update on a change of a power of two would be OK. Another option would be to change the current limit of two MSSes to three, because this would eliminate window updates between regular delayed ACKs. > So, from what I understand, we do back off and that implies we are > losing performance in the FreeBSD to FreeBSD case, right? We do the right thing and ignore these pure window updates. I've checked, and Linux also ignores ACKs that just seem to update the window. David. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
