Date: Mon, 28 Jan 2019 11:29:49 +0000 From: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com> To: "freebsd-transport@freebsd.org" <freebsd-transport@freebsd.org> Subject: RE: IW10 broken when not doing ABC Message-ID: <SN4PR0601MB37284C20493EAFDF13227B2786960@SN4PR0601MB3728.namprd06.prod.outlook.com> In-Reply-To: <SN4PR0601MB37284DE846458AF23AEAA8EB86950@SN4PR0601MB3728.namprd06.prod.outlook.com> References: <SN4PR0601MB37284DE846458AF23AEAA8EB86950@SN4PR0601MB3728.namprd06.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
After some investigation about the most effective course of action, which f= ixes the non-ABC misbehavor and the Special case of the sequence space occupied by the SYN bit, I came up with = the following https://reviews.freebsd.org/D19000 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 cha= nge 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 i= n the code about the processing flow again. A couple of reviewers would be highly appreciated in this core area of sess= ion 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.c= gi?id=3D235256 against this patch. Best regards, Richard -----Original Message----- Hi, Just added this comment to D18940. Would appreciate it, if someone other th= an 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 congest= ion control, but want to discuss them internally first; if anyone is having= time and wants to also investigate, please PM. Best regards, Richard 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=3D0). I suspect, the final ACK of the 3WHS is already processed in the normal A= CK 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/F4= 175462> REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST ACTION https://reviews.freebsd.org/D18940/new/ REVISION DETAIL https://reviews.freebsd.org/D18940 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: rscheff_gmx.at, #transport, tuexen Cc: imp, thj, rscheff_gmx.at _______________________________________________ freebsd-transport@freebsd.org mailing list https://lists.freebsd.org/mailma= n/listinfo/freebsd-transport To unsubscribe, send any mail to "freebsd-transport-unsubscribe@freebsd.org= "
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?SN4PR0601MB37284C20493EAFDF13227B2786960>