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

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.

No. This is typically done by engineers clearing dscp bits but it's the same idea. You as the network engineer should be the one who decides what traffic gets priority or special queuing permissions, not the endpoints. 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. Some routers and firewalls don't even copy the TOS bits from the unencrypted packet to the encrypted packet header.

Now as far as your case is concerned, are you running any real time applications over your network such as voice or video? What kind of router or firewall are you using to tunnel your traffic? If it's an enterprise class device you should be able to strip the ECN bits as they hit the unencrypted interface of the router. Is this tunnel going out over the internet or a private circuit?

Edit:

It is not considered evil because it is you who is responsible for your network, not your users. Therefore it is up to you to decide what traffic to pass and what speeds and queues to assign to that traffic. It's generally considered best business practice to scrub your users' DSCP bits at the ingress and do your own classification of traffic for queuing and congestion control.

Whether or not it is harmful depends on the scenario. It appears that in your scenario your users are coming in from the internet on a vpn tunnel then leaving back out to the internet in the clear. Since the internet is a best-effort network, ECN bits are essentially useless to you because the internet routers will not honor those bits. Typically QoS and congestion control at the transport level are only useful in a network where you can control the devices end to end or where you have a guaranteed rate or SLA with the provider.