Harald Welte wrote: > The only valid use from my point of view is removing the ECT codepoint from > the TCP header of every SYN packet in order to prevent ECN from being > negotiated for a given connection.
If iptables is used for shaping purposes, then setting the IP CE codepoint may also be of value. Harald: ECT above should read ECE+CWR bits. ECT is a dual codepoint in the IP header, after the SYN handshake. Possibly valid iptables ECN capabilities: * Clearing the TCP ECE+CWR bits on SYN to stop ECN from being negotiated for TCP connections. This to work around broken routers/firewalls. When doing this one should also clear the IP ECN field just in case. * Setting the IP ECN CE codepoint to signal congestion, but only if the current IP ECN codepoint is ECT. But as I tried to show before, having the ability to clear the IP ECN field separately from TCP also makes sense if one has control of both sides with a uncontrolled broken device in the middle and there is other protocols utilizing ECN (for example a custom UDP based protocol). But at this time this should be an experimental option to protect the innocent. I think it should be acceptable to have the "clear ECN" target apply blindly.. Always clear the IP ECN field, and if the packet is a TCP packet also clear the ECE+CWR bits. And no, clearing just the IP ECN field do not create additional problems apart from ECN not working, but doing it singlehanded does not solve any problems either as it is not this field that is causing problems today.. Regards Henrik
