Date: Tue, 21 Apr 2020 23:51:21 +0000 From: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com> To: Jonathan Looney <jtl@netflix.com>, Michael Tuexen <tuexen@freebsd.org>, Lawrence Stewart <lstewart@netflix.com>, Randall Ray Stewart <rrs@freebsd.org>, Tom Jones <thj@freebsd.org> Cc: "rgrimes@freebsd.org" <rgrimes@freebsd.org>, "transport@freebsd.org" <transport@freebsd.org> Subject: Categorizing Diffs for Review/Transport Call. Message-ID: <SN4PR0601MB37282AFCDD2062D7C744711386D50@SN4PR0601MB3728.namprd06.prod.outlook.com>
next in thread | raw e-mail | index | archive | help
I thought I'd categorize the Diffs I have currently pending for review into=
different bins;
Those which I deem more critical are those with interoperability issues tow=
ards other stacks (and RFC violations):
23364
24237
24515
23353
Correctness (RFC compliance)
ECN:
23364 (ECN: CWR only with new data) - critical for interoper=
ability with older Linux
23373 (parallel open case - ECN feature)
Interoperability:
24237 (premature window update with outdated SACK - fix alik=
e MacOS and what jtl suggested, by moving upcall to end of input processing=
; side effect is fewer locking issues) - poor performance with most Linux
23371 (parallel open case - feature negotiation)
24515 receive window retraction with window scaling - potent=
ial deadlock with older Linux
Performance
22438 after_idle ssthresh to =BE cwnd per 2861 (performance)
Cubic:
23353 Cubic no minimal cwnd (set to 2 MSS in this diff)
23655 Cubic base_time start only after slowstart is finished
Misc:
21117 optimize TCPCB by replacing unnecessarily large uint64=
_t with uint8_t and bounded increment
23160 SACK partial ACK always activate TT_REXMT instead of T=
T_PERSIST (no longer reproduceable with other cubic fixes) -> abandon?
Feature s:
23230 ECN+ / ECN++ (new sysctl, default disabled; needed for=
DCTCP later)
18624 Improve SACK scoreboard bookkeeping
18892 SACK PRR
18985 RFC6675 SACK (rescue retransmission - for transactiona=
l IO).
Finally, I have AccECN on my plate, but that partially depends on prior boo=
kkeeping fixes, and finalization of the current draft;
Richard Scheffenegger
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?SN4PR0601MB37282AFCDD2062D7C744711386D50>