is clearing the ECN bits from the IP TOS header considered harmfull?

I am considering to clean these bits on the border of our network. Is this considered harmfull or evil?

Some Backbround:

We have ingress traffic from the Internet to some mobiloe Devices behind a IPSec Tunnel's to mobile network operator GGSN's.

+----+    +--------------+       +------------+ Tunnel via +----+     +------+
|Inet|----| Border router|------>|IPSEC-Router|============|GGSN|-----|mobile|
+----+    +--------------+       +------------+ Internet   +----+     +------+

Some of this ingress traffic from the internet is marked with a TOS of 0x03, remarkably all traffic from a german cable ISP named UnityMedia.

For a at the moment unknown reasons the IPSec Implemetation on the IPSec Router decides to throw away all packages marked with a TOS of 0x01 or 0x03. Regarding this I had a question asked here.

As workaround I would remove the ECN related bits from the TOS field on my border router but on the other side I am not sure if I could generate a new problem by doing so, and therefore my question:

Is this considered harmfull or evil?

Sorry, mod me down if applicable: I don't have enough mod points to vote down or add remarks.

The answer resmon6 gave sounds really bad and ignorant to me. He talks about TOS and DSCP as if it's the same as ECN. ECN is totally different and should be left alone and allowed to work!

resmon6:

You as the network engineer should be the one who decides what traffic gets priority or special queuing permissions"

Really? And that has to do with ECN how exactly?

resmon6:

It's also very likely that most of the routers in the path don't have ECN queuing enabled, definitely not if it's going over the internet.

Very far from the truth as far as I know. All Operating Systems and routers of the last decade or more support ECN and at least Linux has it partially enabled by default if I remember correctly and certainly NOT "all internet routers" disable ECN. There are a few bad apples (black holes) but by and large it works.

It's only ignorant people purposely breaking ECN that make it such problem for others to use it.

resmon6:

It is not considered evil because it is you who is responsible for your network, not your users.

What nonsense! As long as the traffic is not harmful you need to let your users do how they wish: net neutrality and all that. ECN is good for everyone: you and your users. Your statement makes no sense at all!

All you need to do to not f*ck with ECN is ignore it. Simply do nothing. Why in hell would you want to disable it?

Seriously... at least glance over the wikipedia page if you have no clue what ECN is before answering questions pretending to be an expert!

http://en.wikipedia.org/wiki/Explicit_Congestion_Notification

DSCP is not in there at all and the only TOS is in the word 'macintosh'! FCOL!

The Opposite of Priority

Clearing the ECN field to zero within the network is very harmful to other traffic, and never useful.

Because ECN notifies congestion, it has the opposite effect to priority. So if you wipe ECN from certain traffic, you give an extreme advantage to that traffic versus others.

Explanation: The most common location of a bottleneck where packets are marked with Explicit Congestion Notification (ECN) is at the home gateway router into the Internet. If at some point further into the network, you clear the ECN field, the sender(s) will be blind to any bottleneck congestion. They will then send faster and faster until they overrun the bottleneck buffer, causing packet loss after adding a large amount of queuing delay.

Altho it's not pleasant, the senders of the packets you are mangling can cope with losing the benefit of ECN... However, it's everyone else that suffers. If some of the traffic passing through the same bottleneck goes off elsewhere in the Internet (rather than through the point where you're mangling), it will still see the extreme congestion notification as the buffer overruns (because you are not concealing it from everyone by your meddling). So the other traffic will rapidly cut its rate and starve.

Proper Solution

If a VPN tunnel egress is dropping packets with the ECN field set to 0x3, it will be because the ECN field on the inner IP header is 00. That's what a tunnel is meant to do, according to the ECN spec's [RFC3168]. The solution is not to blindly clear the ECN field on all packets (which will cause the above problems). The proper solution is to ensure ECN is not set to 0x3 on packets that started out with ECN == 0. Because that is an illegal transition according to the ECN spec (which is why the VPN egress drops them).

20th Century Dinosaurs

The 8-bit Type of Service field in the IP header (v4 & v6) was redefined in Dec 1998, and split into 6 bits for Differentiated Services, and 2 bits for Explicit Congestion Notification (ECN).

Only dinosaurs who are still living in the 20th century (resmon6 included), think that the ECN field is still something to do with prioritization.