Follow RFC6675 for setting sshthresh and cwnd at fast retransmit.
As discussed on the transport call, this would let people experiment.
Differential D6105
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 Tags None Referenced Files
Subscribers
Details
Diff Detail
Event TimelineComment Actions Why isn't there simply a do_rfc6675 knob that supersedes this and the previously committed work? Comment Actions For more granular control. We can merge them all into one later once we are satisfied with the behavior. Comment Actions 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. This comment was removed by hiren. Comment Actions iirc, @rrs tried the patch and it didn't work well for his workload. I Having said that, I know putting it under one knob looks more correct. Comment Actions That's good reasoning for more testing, not good reasoning for piecemeal implementation and control knobs.
s/looks/is :) Comment Actions 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. Comment Actions 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. :-)
https://mailarchive.ietf.org/arch/msg/tcpm/515zSdL2uD77ezV4-MDnoshDNbI
I'd also have to look. Comment Actions Add cwnd and ssthresh recommendations to RFC 6675 support. While here, unify everything under one sysctl knob. Comment Actions 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.) Comment Actions 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: RFC6675 says: (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. |