Setting ssthresh more accurately on loss.

[hiren]

Summary

Set slow start threshold more accurately on loss to be flightsize/2 instead of
cwnd/2 as recommended by RFC5681.

[hiren]

This is a bug exposed by recent commit https://svnweb.freebsd.org/base?view=revision&revision=307901

Thus I'd appreciate any reviews soon.

[hiren]

Also restore pre-r307901 behavior of alighning ssthresh on MSS boundary.

[sbruno]

I've reverted this from -current at svn R308180. Please discuss here.

[rscheff]

@sbruno: is there any log as to why the revert happend?

I'm asking, because for a very long time, the following behavior would ensue:

While application limited, the session never sees any loss - and cwnd can grow all the way to the receiver window. While at the same time, only a fraction of that window is in active use (only so much data is outstanding, to match the appliction transmit rate).

Now, when a loss actually happens (e.g. the application starts sending at higher speeds, or the network conditions change), ssthresh = cwnd/2 - but cwnd can be significantly inflated at this time already. Thus it takes multiple rounds of multiplicative decrease (more losses than absolutely necessary) for ssthresh and cwnd to get pulled back to a more reasonable, value...

Using flightsize (or a properly calculated rfc6675 pipe) would address that scenario - and should limit the number of loss recovery episodes needed to arrive at a good new cwnd.

Now, D21798 addresses this particular problem differently (by no longer growing cwnd, when the session is application limited).

But it's conceivable that an application reduced its sending rate prior to the CC reaction - so while cwnd no longer grows "unbounded", it may still not be a good reflection of the current state of the network...

Just curious if this shouldn't be revived - but curious for the reasoning about the revert first.

[sbruno]

I think we need @hiren for further details for this revert. I believe he asked me to undo this.