ssthresh = max (cwnd / 2, 2*MSS)
instead of cutting it to half the *effective* window:
ssthresh = max (min (cwnd, rwnd) / 2, 2*MSS)
as BSD does (p. 845 stevens vol II) and the draft spec on TCP congestion
control
http://www.ietf.org/internet-drafts/draft-ietf-tcpimpl-cong-control-00.txt
says you ought to. This is funny because this note says that this is a
common mistake, *and* comments in the Linux code seem to indicate that one
of the linux coders thought of this problem case but didn't know how to
handle it:
* FIXME: What happens when the congestion window gets larger
* than the maximum receiver window by some large factor
* Suppose the pipeline never looses packets for a long
* period of time, then traffic increases causing packet loss.
* The congestion window should be reduced, but what it should
* be reduced to is not clear, since 1/2 the old window may
* still be larger than the maximum sending rate we ever achieved.
this is the actual code that looks suspicious to me. it is executed when
the RTO timer fires:
if (tp->retransmits == 0) {
/* remember window where we lost
* "one half of the current window but at least 2 segments"
*/
tp->snd_ssthresh = max(tp->snd_cwnd >> 1, 2);
tp->snd_cwnd_cnt = 0;
tp->snd_cwnd = 1;
}
This seems to be a bug that would set ssthresh up to 1.5x too high in some
cases, which seems potentially very serious. So, am i delerious from
quals, or is this something we should tell somebody important about,
especially since they're in a big push to get the bugs out of 2.1.x before
they call it 2.2 (an official "stable" release).
neal