Page MenuHomeFreeBSD

Setting ssthresh more accurately on loss.
Needs ReviewPublic

Authored by hiren on Oct 26 2016, 10:40 PM.



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

Diff Detail

rS FreeBSD src repository - subversion
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

hiren retitled this revision from to Setting ssthresh more accurately on loss..
hiren updated this object.
hiren edited the test plan for this revision. (Show Details)
hiren added a reviewer: jtl.
hiren added a subscriber: transport.

This is a bug exposed by recent commit

Thus I'd appreciate any reviews soon.

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

This revision was automatically updated to reflect the committed changes.
sbruno added a subscriber: sbruno.

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

@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.

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