Follow RFC6675 for setting sshthresh and cwnd at fast retransmit.
As discussed on the transport call, this would let people experiment.
Add cwnd and ssthresh recommendations to RFC 6675 support. While here, unify everything under one sysctl knob.
hiren on Apr 26 2016, 12:34 AM.Authored by
But why do we need such finely grained control? I don't get it. Either it works or it doesn't. We shouldn't be doing 6675 piecemeal. We should be doing 6675 in full and enabled by default. Providing any level of minutiae beyond enabled/disabled is not only unnecessary but a bad idea IMO.
That's good reasoning for more testing, not good reasoning for piecemeal implementation and control knobs.
FWIW, I agree with @lstewart; however, I think we should avoid an unqualified "RFC 6675" name until we actually implement all of RFC 6675. Maybe I'll actually get to the rest of it this summer.
Regarding the patch, I'm curious why you chose the formula you did on one 2644-2645. The RFC refers to "Flight Size" from RFC 5681, which is not necessarily the same thing as "pipe". Also, the full formula from RFC 5681 is:
ssthresh = max (FlightSize / 2, 2*SMSS)
It isn't clear to me why the 2*SMSS floor was dropped from RFC 6675's restatement.
I've been testing with these things and I wanted broader testing from others in the community. If we don't want to go ahead with this, I can abandon this rev and we'd still have patch available with granular knobs for people to test/verify.
Once we have full RFC6675 support, we can come back and do it.
I am fine either-ways. :-)
I'd also have to look.
I don't have time to fully think about this today; perhaps, we can discuss it in Ottawa.
I'm on the fence about the sysctl name. I also need to think further about "flight size" vs. "pipe". I read the IETF mailing list discussion, but I don't think it directly answered the question. (But, it may just be lacking some thought from me.)
At hackers lounge BSDCan, @jtl and I discussed this and realized that I was incorrectly interpreting rfc.
Let's try to decompose whats being proposed by RFCs:
(4.3) Retransmit the first data segment presumed dropped
(4.4) Set pipe.
Now, looking at RFC5681
FLIGHT SIZE: The amount of data that has been sent but not yet cumulatively acknowledged. i.e. SND.MAX - SND.UNA
In 3.2. Fast Retransmit/Fast Recovery
Eq (4) ssthresh = max (FlightSize / 2, 2*SMSS)
i.e. if you want to follow RFC5681 strictly, it says, on 3rd dupack, set sshthresh and after retransmitting first lost seg, set cwnd. Which differs from what RFC6675 says.
I'll try and update the code tomorrow.