On Feb 12, 2005, at 6:31 AM, Alexey Kuznetsov wrote:
In some cases at least if the sender does not completely fill cwnd
ACKs will be delayed. And IIRC under 2.6.10 with TSO enabled, the
sender does not always fill cwnd.
At a maximum, "1/tcp_tso_win_divisor" of the cwnd will ever be left
By default, this is 1/8 of the cwnd.
In any case, receiver cannot know sender cwnd, so that "fill" or "not
is is not a question.
How is that? Isn't cwnd based on the ACKs the sender receives from the
What is broken in that implementation is that it does not feel slow
ACK avoidance while slow start is certain disaster. Currrent theory is
MacOS X thinks that we do not do slow start.
Actually, it may think slow start is being done - there was enough
small packet back and forth on the connection before the "heavy
transfer" to get cwnd opened - I just didn't quote that in the "cooked"
output. All the stacks with ACK avoidance with which I am familiar do
not make the assumption that the sender is not doing slow-start. They
make sure to send enough ACKs at the beginning (or after packet loss)
to allow the sender's cwnd to grow.
wisdom teeth are impacted, people are affected by the effects of events