IW10 broken when not doing ABC
Richard.Scheffenegger at netapp.com
Mon Jan 28 11:29:53 UTC 2019
After some investigation about the most effective course of action, which fixes the non-ABC misbehavor and the
Special case of the sequence space occupied by the SYN bit, I came up with the following
It's also fixing the smaller nuisance of the 1 byte cwnd inflation for SYN when doing ABC.
In case the SYN,ACK or final ACK already contain data, this patch won't change the processing order.
The common case of these segments containing no data is handled by updating snd_una before additional
ACK processing can inflate the initial window, matching previous comments in the code about the processing
A couple of reviewers would be highly appreciated in this core area of session set-up, so that I've not missed any side-effect.
Also, I don't know how to bind https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235256 against this patch.
Just added this comment to D18940. Would appreciate it, if someone other than me can confirm this behavior, which may have been present for some time already.
Also, I found some other oddities around ABC calculation in modular congestion control, but want to discuss them internally first; if anyone is having time and wants to also investigate, please PM.
Subject: [Differential] D18940: Consolidate Initial Window calculations
I was just starting to validate something around RTO, and found, that the effective IW is now actually 11 SMSS, not 10 MSS, when NOT doing ABC (net.inet.tcp.rfc3465=0).
I suspect, the final ACK of the 3WHS is already processed in the normal ACK path, increasing cwnd at that point by one MSS.
Here is the corresponding Packetdrill script (named for what I wanted to validate, before hitting this).
F4175462: newreno-slowstart-after-rto.pkt <https://reviews.freebsd.org/F4175462>
rS FreeBSD src repository
CHANGES SINCE LAST ACTION
To: rscheff_gmx.at, #transport, tuexen
Cc: imp, thj, rscheff_gmx.at
freebsd-transport at freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-transport
To unsubscribe, send any mail to "freebsd-transport-unsubscribe at freebsd.org"
More information about the freebsd-transport