How to enable AccurateECN when using L4S queue management?

I need a little more context: Are the Linux devices local to you, so that you are sure there is nothing (like a proxy) between your Mac Mini and the Linux server? How are you determining what the TCP flags are on your SYN? Wireshark? (if so, you might need to check it's an up-to-date version that recognizes the AE flag)

@BobBriscoe Thanks for your reply! Let me share you some details:

The Linux devices are directly attached to the Ethernet ports on the Mac. There's nothing in between them.

The two Ethernet ports on the Mac are configured with a static IP and they have different subnets:

• Mac Ethernet Port 1 (built-in port): is configured with static IP 1.1.1.1/24 with itself (1.1.1.1) as the gateway
• Mac Ethernet Port 2 (USB adaptor): is configured with static IP 2.2.2.1/24 with itself (2.2.2.1) as the gateway
• The endpoints are configured as 1.1.1.2/24 and 2.2.2.2/24 respectively.
• (There's no internet access, so should be safe to use public IPs for this experiment.)

I capture using tcpdump on the Linux endpoints themselves and later open the captures with Wireshark:

• Client endpoint capture: I can see that the initial SYN is sent out correctly with 3 flags: AE, CWR and ECE.
• Server endpoint capture: I see the same SYN arriving with only 2 flags: ECE, CWR. (The same ** SYN**, not SYN-ACK!)

The Wireshark is modern enough to recognize the AE flag and the Accurate ECN options in the TCP header.

Maybe the static IP config is somehow affecting the result? I'm willing to do more experiments if needed. Just let me know if you need more info.

@BobBriscoe yes, the Wireshark is recent and can show the AE flag and the Accurate ECN options in the TCP header. The two ethernet ports are configured with a static IP in different subnets (so routing is required, which is needed for L4S). I'm capturing on the devices directly (using tcpdump, and open them Wireshark). The devices are directly connected to the Mac (no proxy or anything.)

@StackedCrooked

I'm trying to use L4S queue management feature in MacOS Sonoma. I've followed the online guides: "Reduce network delays with L4S" and "Testing and Debugging L4S in Your App". Basically I setup "Internet sharing" to allow traffic to pass through a Mac Mini using Linux devices as the endpoints. (This requires two ethernet ports so I use an USB Ethernet adapter > as the second port).

L4S guidelines on "Testing and Debugging L4S in Your App" are for enabling Apple end points to negotiate and do L4S/Accurate ECN. Since you are using Mac only for sharing internet, you don't need to enable anything if L4S/Accurate ECN negotiation is happening between Linux end points.

Anyone know why this happens. Do I need to enable something? I have used the following: defaults write -g network_enable_l4s -bool true And also tried an undocumented (?) sysctl option: sysctl -w net.inet.tcp.accurate_ecn=1

You don't need to enable any of the above if you are using Mac only for internet sharing. Those are needed if you use Apple device as client or server.

Does anyone know how to get the AccurateECN negotation to work?

You'd need to check if both of your Linux machines are using L4S kernel and Prague congestion control. You can check the "Performing Experiments" section here. Once you have confirmed the sysctl settings, you can take a Wireshark capture at sender linux, Mac (both incoming and outgoing interface through which Internet is shared) and receiver linux. For simplicity, you can just connect the two linux machines directly without a Mac in between.

You don't need to enable any of the above if you are using Mac only for internet sharing. Those are needed if you use Apple device as client or server.

I believe I do need to enable network_enable_l4s because I want the Mac to generate the ECN markings when the queue is building. That's the whole point of the "L4S queue management feature in MacOS Sonoma". (Am I wrong?)

Yes, the Linux endpoint have the L4S kernel and are using TCP Prague as the congestion avoidance algorithm. The problem is that the Mac Mini is stripping one of the ACE flags in the initial SYN message. YES the Mac is modifying the flags of the TCP header!