Re: [PATCH net-2.6 0/3]: Three TCP fixes

[Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>]

Hello!

> My theory is that it could relate to tcp_cwnd_restart and 
> tcp_cwnd_application_limited using it and the others are just then 
> accidently changed as well. Perhaps I'll have to dig once again to 
> changelog history to see if there's some clue (unless Alexey shed 
> some light to this)...

Yes, it is RFC2861. There is some rationale in preamble to section 3.
But even for this case it can be set to full cwnd instead.

Also, I used it to calculate prior_ssthresh to restore ssthresh
in the case when we detect false retransmission. It is not an accident.
I really mean that tcp_current_sshresh() is correct estimate
for "current ssthresh" and this should be the same as in restart
situation. Of course, rationale of RFC2861 does not apply
to this case _directly_. But it was at the end of chain of syllogisms.

Look:

If we have not infinite ssthresh and cwnd > ssthresh, we are already
in congestion avoidance mode and we can set prior_ssthresh to any value
in the range ssthresh...cwnd without significant changes in behaviour
wrt congestion avoidance.

ssthresh would be an obvious underestimate.

cwnd can be an overestimate, because the path is surely congested
(cwnd > ssthresh) and cwnd is not a measure of current capacity.

Behavioral changes happen, when final cwnd is too low, because pipe
was drained during recovery. We allow to slow start to sshresh,
but value of ssthresh should be the same as we use for restart case.

Alexey