Well heck. No, I hadn't thought about [the lack of] sudo being the issue. sigh My apologies, and thanks for setting me straight there.
32706 client connections attempted to negotiate ECN
1725 client connections successfully negotiated ECN
10959 times graceful fallback to Non-ECN connection
49275 times lost ECN negotiating SYN, followed by retransmission
188 server connections attempted to negotiate ECN
171 server connections successfully negotiated ECN
17 times lost ECN negotiating SYN-ACK, followed by retransmission
170 times received congestion experienced (CE) notification
3 times CWR was sent in response to ECE
4349 times sent ECE notification
92 connections received CE atleast once
3 connections received ECE atleast once
1164 connections using ECN have seen packet loss but no CE
61 connections using ECN have seen packet loss and CE
34 connections using ECN received CE but no packet loss
2 connections fell back to non-ECN due to SYN-loss
44 connections fell back to non-ECN due to reordering
1 connection fell back to non-ECN due to excessive CE-markings
1 connection fell back caused by connection drop due to RST
0 connection fell back due to drop after multiple retransmits
6 connections fell back due to RST after SYN
I have to admit that report does not make a whole lot of sense. The ecn attempt failures was really high, seeing loss and ecn marks also quite weird. I am assuming this was over wifi?
net.inet.tcp.ecn_negotiate_in doesn’t exist anymore. It should be removed from a plist, if you’re using that.
net.inet.tcp.ecn is new. Probably should be added if you want to be sure ECN remains on.
net.inet.tcp.disable_tcp_heuristics remains disabled by default. I wouldn’t be so eager with enabling it, because there could be servers out there without ECN. It also affects other TCP stuff like TCP Fast Open (TFO) and MPTCP. When these fail to negotiate OS will put hosts on a (temporary?) blacklist and perform regular TCP.