Tak zrovna u TCP SACK je naopak obecne doporucovano jej v nekterych (bezne provoznich) situacich vypinat, takze zas takove drama bych z toho nedelal :-) Obecne plati, ze ne vse defaulne nastavene v distribuci je univerzalne optimalni - a dopady tohoto kroku (pozitiva i negativa zmeny s ohledem na lokalni prostredi) by si kazdy mel zhodnotit sam dle sveho prostredi nezavisle na tom, ze zrovna vysla nejaka bezpecnostni advisory...
Kvuli zmrsenym implementacim stejne tak muzou nastat problemy pri zahazovani paketu s nizkym MSS v duchu mitigacnich kroku k CVE-2019-11479 - a zde se mnohdy argumentuje modernim IoT, kde to muze byt problem. Jak uz jsem psal, aplikace workaroundu vzdy zalezi na konkretnich podminkach.
Stejne tak duvodem pro vypnuti TCP SACK v kernelu muze byt nejen zmrsena implementace, ale nekdy i vykonnova optimalizace - ono si to vezme nejaky ten procesorovy cyklus navic, zapnute to dava smysl hlavne na linkach s vysokou latenci, nebo tam kde je packet-loss.. Ostatne to, ze to je dobry sluha, ale nekdy zly pan dokazuje treba i lonsky commit do 4.18, kde to je pekne i popsane (fuel to fire) - ale zas muzeme obratem vest flame o tom, ktere distribuce maji tak "cerstvy" kernel ;-)
To, že se dá v konkrétních situacích algoritmus ještě zefektivnit, nemění nic na skutečnosti, že se SACK je zotavení se ze ztracených paketů mnohem efektivnější než bez něj. To už bych klidně mohl argumentovat třeba tímhle problémem, který se projevoval jen bez SACK - a chování v takovém případě bylo řádově horší než to, co řeší SACK compression. Mimochodem, autor patche, kterým argumentujete, napsal o nějaké dva měsíce dříve třeba tohle - z toho je, myslím, jeho názor na zakazování (nebo nepodporu) SACK, dost zřejmý.