Date: Sat, 22 Dec 2018 00:06:03 +0000 From: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com> To: "freebsd-transport@freebsd.org" <freebsd-transport@freebsd.org>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: RFC6675 Message-ID: <SN4PR0601MB3728F3901A5A61770235861086B90@SN4PR0601MB3728.namprd06.prod.outlook.com> In-Reply-To: <SN4PR0601MB37289C7E2CCFEDBF357B528586DB0@SN4PR0601MB3728.namprd06.prod.outlook.com> References: <SN4PR0601MB37289C7E2CCFEDBF357B528586DB0@SN4PR0601MB3728.namprd06.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
For those inclined, I have a working patch for full RFC6675 support now (ne= ed to validate pipe and behavior in various scenarios still): a) enters Loss Recovery on either Nth dupack, or when more than (N-1)*MSS b= ytes are sacked (the latter relevant for ack thinning) b) a cumulative ack below snd_max, while snd_max =3D=3D recovery_point (app= lication limited) no longer requires a lengthy RTO and slow start to recove= r from. Instead, the Rescue Retransmission mechanism is implemented. c) proper accounting for delivered_data and sacked_bytes in the single-pass= update of the scoreboard. These variables enable further mechanisms like P= roportional Rate Reduction. Also, this fixes potential exploits by maliciou= s clients, and support thin IoT clients that can store data to the right of= rcv_ack, but not keep state for a full RFC3517 compliant scoreboard. I certainly need reviewers, if you are interested please let me know so tha= t I can sign you in for it. Also, further testing would be required. Best regards, Richard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?SN4PR0601MB3728F3901A5A61770235861086B90>